Re: [gentoo-portage-dev] [PATCH] Document bugzilla workflow

[Sebastian Luther <SebastianLuther@gmx.de>]

Am 15.01.2014 04:11, schrieb Tom Wijsman:
> On Wed,  8 Jan 2014 19:25:19 +0100
> SebastianLuther@gmx.de wrote:
> 
>> From: Sebastian Luther <SebastianLuther@gmx.de>
> 
> Can you fix your git config too? See vapier's feedback on creffet.

I'll take a look.

> 
>> +Bugzilla
>> +--------
> 
> More discussion is needed before we should add this; at least I think
> it should be brought up during the meeting this Sunday, because we've
> barely had feedback and at least one suggestion doesn't appear
> discussed and/or incorporated.

I send the first mail with this wording 8 days ago. Enough time to
comment on it. I'd prefer to discuss it on the list.

> 
> I've commented on the suggestion by dol-sen which I like the most;
> especially the assignment part, I think it also contains some other neat
> additions.
> 
> Besides that, I'll comment my thoughts on some of the other parts here:
> 
>> +There always exists a tracker bug, named:
>> +"[Tracker] sys-apps/portage-<next version>".
>> +
>> +This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until
>> +it gets closed when Y changes and a new one is opened.
> 
> While this spares out on tracker bugs, we lose the ability to track
> which bugs were fixed in which version, 

That's not true. Just look at the tracker for 2.2.9. Between the renames
of the tracker you'll see which bug has been marked as blocking. These
are the fixed ones.

unless we enforce that all bug
> numbers get to be listed in the ChangeLog; do we have a policy for that?

The numbers go into the ebuild changelog, but I don't think that's
written down somewhere (/me looks at dol-sen).

> 
>> +Whenever a commit for a specific bug is made to the git repo,
>> +the corresponding bug gets changed in the following ways:
>> +* InVCS is added to Keywords
>> +* The bug is marked as blocking the tracker for the next version
>> +* A comment is added saying: This is fixed in git: <url to commit>
>> +(note that the bug stays open)
> 
> +1
> 
>> +After a release all open bugs blocking the tracker are closed
>> +with the comment "This is fixed in <version>.".
> 
> +1
> 
>> +For individual open bugs it is encouraged to set UNCONFIRMED,
>> +CONFIRMED or IN_PROGESS as appropriate.
> 
> What is "as appropriate"? As I mentioned, this needs more discussion;
> please keep this the way it was, it makes the tracker bug more useful.

The "way it was" is to not care about them at all. There was no
agreement on the the other thread if these things should be used or not.
So I left it vague so everyone could use it, but they are not forced to.

> 
>> +There are a number of bugs named "[TRACKER] *" that collect bugs
>> +for specific topics. Confirmed bugs should be marked as blocking
>> +these tracker bugs if appropriate.
> 
> For clarity, it should be mentioned that this does not mean to block
> the tracker for the next version; this could be misinterpreted.

Considering that the tracker gets renamed, I'm not sure what you mean here.

> 
>> +It is encouraged to set the alias field for frequently used bugs.
> 
> Yes, but please set it to something specific enough; I'm tired of
> searching for a random word and get into one or another old bug.
> 
Most likely candidates are the trackers.