Re: Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

Duncan wrote:
> I'm a user, and despite the fact that I tend to run ~arch or even pre-tree
> testing overlays, I find ebuild removal information in the changelog WAY
> more useful than, say, when some obscure arch keyworded a version.
>
> Ergo, the argument that users don't find that info useful is disproven.
> Users DO find it useful.  I /as/ a user find it useful and get rather
> annoyed when I'm trying to trace a change and there's no entry at all for
> it in the changelog!
>
> So, please /do/ make ebuild removal entries in the changelog, as users
> /do/ find them useful. =:^)
>
>    

I'm a user, tho a lowly one, and even I look in the changelogs from time 
to time.  I don't even see why this should be discussed.  If you 
*change* something, but it in the *change* log.  If not, maybe the 
changelog should be called something else.

Using the logic that something being removed is not a change, then 
adding something is a change either.  Adding something is important and 
I think something being removed is important too.

Dale

  

Re: Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

Dale wrote:

I'm a user, tho a lowly one, and even I look in the changelogs from time to time.  I don't even see why this should be discussed.  If you *change* something, but it in the *change* log.  If not, maybe the changelog should be called something else.

Using the logic that something being removed is not a change, then adding something is a change either.  Adding something is important and I think something being removed is important too.

Dale

I'm a user, tho a lowly one, and even I look in the changelogs from time to time.  I don't even see why this should be discussed.  If you *change* something, put it in the *change* log.  If not, maybe the changelog should be called something else.

Using the logic that something being removed is not a change, then adding something is not a change either.  Adding something is important and I think something being removed is important too.

Dale

   

P. S. Corrected some bad typos.  lol  I need new glasses and better fingers. 

Re: Bugzilla - New Default Status Workflow

On Thursday 28 of April 2011 16:07:24 Christian Ruppert wrote:
> So once again:
> 
> https://bugs.gentoo.org/docs/en/html/lifecycle.html
> 
> *Every* new bug filed by a user without editbugs will have "UNCONFIRMED"
> (old NEW) as fixed status.
> *If* we don't enable the UNCONFIRMED status at all then it will
> CONFIRMED as default but we would enable the UNCONFIRMED status.
> 
> Bug wranglers can then assign the bug and they also *can* mark it as
> CONFIRMED *if* they *can* confirm it.
> The maintainer may change the status to IN_PROGRESS (old ASSIGNED)
> afterwards.
> 
> The snipped of my first mail may be a bit confusing... It just means:
> NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so
> NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED
> would/could be the default for everybody with editbugs.
> ASSIGNED gone, replacement: IN_PROGRESS,
> REOPENED gone,

+1 (with comment, see below)

It makes a lot more sense (and it's free from enterprisey meaning wrt ASSIGNED 
and such)

I'd leave the default resolution status for newly created bug as UNCONFIRMED 
also for editbugs-accounts. It's not that it cannot be changed to CONFIRMED in 
'new bug' extended form.

> CLOSED gone. VERIFIED will be added.

I have a little worry thought (that may have been addressed somewhere in this 
thread) - why is VERIFIED being added? To me it's not needed at all and there 
are people who seem to have the same opinion:

http://www.mail-archive.com/gentoo-dev <at> lists.gentoo.org/msg39023.html

--

-- 
regards
MM

Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

>>>>> On Fri, 29 Apr 2011, Michał Górny wrote:

>> Among the options I see is the following:
>> 
>>  A) Find out how to render g-metal.blend with recent Blender
>>     (2.57b at best) to give pixel-identical results to Blender 2.04.
>>     Needs an advanced Blender user ideally.
>> 
>>  B) Port Blender 2.26 to a recent version of Python.
>> 
>> Are there any other options?

Could you bisect Blender to find out why it doesn't work with the new
version?

> Maybe it's time to make the SVG variant the official logo, and leave
> the blender file as a historical variant.

The Blender variant looks better though, especially at high
resolutions.

Ulrich

Re: Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

On Sun, 1 May 2011 06:10:02 +0200
Ulrich Mueller <ulm <at> gentoo.org> wrote:

> > Maybe it's time to make the SVG variant the official logo, and leave
> > the blender file as a historical variant.
> 
> The Blender variant looks better though, especially at high
> resolutions.

Isn't it possible to create a better SVG then? I think such a variant
would be much more portable and reproducible than blender files.

--

-- 
Best regards,
Michał Górny

Re: Devmanual text on ChangeLogs

On 04/30/2011 11:39 PM, Panagiotis Christopoulos wrote:
> On 12:02 Sat 30 Apr     , Samuli Suominen wrote:
>>
>> "Every new file, and modification to existing file should have an entry
>> in ChangeLog." to skip the proper ChangeLog-less removals.
> 
> There is something I can't undestand reading all the previous
> discussions. You disagree with logging removals only because you don't
> like the idea (you think it's useless information) or also because if
> this becomes a policy, it will increase more the size of ChangeLogs? You
> (and others) would still be negative if the problem with sizes etc. was
> solved somehow?
> 

No, but because of the quantity of commits[1] as a result of maintaining
subset of issues tree wide at once (like libpng, jpeg, libnotify, *kit,
u{disks,power}, lcms, fixing missing includes due to toolchain changes,
adding some consts, imagine the rest ...)

... the time alone if you have to stop on each package to wait for
echangelog to get done just doubles the amount of time you have to put
into committing them. That's just not worth the effort.

So not only they are rather useless, and information you can easily get
from sources.gentoo.org, they take your time as well.

Re: Bugzilla - New Default Status Workflow

On 04/30/2011 10:40 AM, Christian Ruppert wrote:
> On 04/28/2011 04:07 PM, Christian Ruppert wrote:
>> So once again:
>>
>> https://bugs.gentoo.org/docs/en/html/lifecycle.html
>>
>> *Every* new bug filed by a user without editbugs will have "UNCONFIRMED"
>> (old NEW) as fixed status.
>> *If* we don't enable the UNCONFIRMED status at all then it will
>> CONFIRMED as default but we would enable the UNCONFIRMED status.
>>
>> Bug wranglers can then assign the bug and they also *can* mark it as
>> CONFIRMED *if* they *can* confirm it.
>> The maintainer may change the status to IN_PROGRESS (old ASSIGNED)
>> afterwards.
>>
>> The snipped of my first mail may be a bit confusing... It just means:
>> NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so
>> NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED
>> would/could be the default for everybody with editbugs.
>> ASSIGNED gone, replacement: IN_PROGRESS,
>> REOPENED gone,
>> CLOSED gone. VERIFIED will be added.
>>
>> So I think we should convert...
>>
> 
> I think I'll convert the workflow in about 24h if nobody really
> complains. There is more positive feedback anyway.
> 

Done. The new workflow is online.

--

-- 
Regards,
Christian Ruppert
Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure
member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8

Re: Bugzilla - New Default Status Workflow

On 05/01/2011 11:39 AM, Christian Ruppert wrote:
> On 04/30/2011 10:40 AM, Christian Ruppert wrote:
>> On 04/28/2011 04:07 PM, Christian Ruppert wrote:
>>> So once again:
>>>
>>> https://bugs.gentoo.org/docs/en/html/lifecycle.html
>>>
>>> *Every* new bug filed by a user without editbugs will have "UNCONFIRMED"
>>> (old NEW) as fixed status.
>>> *If* we don't enable the UNCONFIRMED status at all then it will
>>> CONFIRMED as default but we would enable the UNCONFIRMED status.
>>>
>>> Bug wranglers can then assign the bug and they also *can* mark it as
>>> CONFIRMED *if* they *can* confirm it.
>>> The maintainer may change the status to IN_PROGRESS (old ASSIGNED)
>>> afterwards.
>>>
>>> The snipped of my first mail may be a bit confusing... It just means:
>>> NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so
>>> NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED
>>> would/could be the default for everybody with editbugs.
>>> ASSIGNED gone, replacement: IN_PROGRESS,
>>> REOPENED gone,
>>> CLOSED gone. VERIFIED will be added.
>>>
>>> So I think we should convert...
>>>
>>
>> I think I'll convert the workflow in about 24h if nobody really
>> complains. There is more positive feedback anyway.
>>
> 
> Done. The new workflow is online.
> 

Before I forgot.. You may have to update your saved searches in
Bugzilla. In the most cases its just that "UNCONFIRMED" has not been
selected.

--

-- 
Regards,
Christian Ruppert
Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure
member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8

Re: Devmanual text on ChangeLogs

On 30-04-2011 11:46:37 +0300, Petteri Räty wrote:
> http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
> 
> There doesn't seem to be a common opinion on what the policy for
> ChangeLog entries is. See:
> 
> http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml
> 
> I propose a simple new text: "Every commit should have an entry in
> ChangeLog." If we eventually autogenerate them from git logs this would
> happen any way (unless some kind of filtering system is in the middle)
> so we could already start now. I think it's better to have more than
> less information available to users.

Because everytime we need something more sophisticated people come up
with the holy git grail, here is the script to generate a
echangelog-style ChangeLog from CVS, right here, right now.

It's a naive implementation, but the output shows the differences
between the committed log, and what would be generated from CVS.  (The
usernames could be looked up easily, but I was too lazy to do that.)
People can use this to judge if "autogeneration from VCS" is a good
thing or not.

My conclusion is that you probably want to maintain the ChangeLog
manually.

I also attached a sample of the script output for net-p2p/transmission
for convenience.

--

-- 
Fabian Groffen
Gentoo on a different level

git? [was: Re: Devmanual text on ChangeLogs]

On Sun, May 01, 2011 at 12:06:47PM +0300, Samuli Suominen wrote:
> ... the time alone if you have to stop on each package to wait for
> echangelog to get done just doubles the amount of time you have to put
> into committing them. That's just not worth the effort.

Won't moving the tree to git will make this a moot discussion?  These and
similar solutions look more and more lika a band-aid to the defecencies
of cvs.

What is it really that is holding us up?  A dev to spearhead the move?

--

-- 
Eray Aslan
Developer, Gentoo Linux       eras <at> gentoo.org