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

[Tom Wijsman]

On Wed, 15 Jan 2014 07:29:19 +0100
Sebastian Luther <SebastianLuther@×××.de> wrote:

> Am 15.01.2014 04:11, schrieb Tom Wijsman:
>
> > 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.

Yes, but not all comments were discussed yet, therefore (dis)agreement
on them is missing; and this last thing rather became a topic of
discussion due to the work clashes that we saw happen twice.

> >> +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.

Good point, thanks; a small problem is when bugs get reopened, but I
suppose this wouldn't happen too often to be a big problem.

> 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).

Yes, I see some commit messages not refer to bugs which is something we
will want to avoid; think this might need to go into the commit policy.

> >> +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.

Hmm, could this result in conflicting usage of these?

The "way it was" means the way the previous Portage team did it.

Being able to see IN_PROGRESS when it is in VCS on the tracker is
really handy, as that avoids skipping bugs; for those that deem that
mouse-over is unhandy, an alternative way is to see the open list is: 

https://bugs.gentoo.org/buglist.cgi?quicksearch=blocked%3A484436

> >> +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.

As you are confused yourself by misinterpreting what you have written,
you demonstrate the case for the need of clarity here; this is not
about the next version tracker or it being renamed at all, it's about
all other trackers that are not version trackers. The part of the
policy quoted here doesn't make that clear, it had me puzzling for a
moment too when I first read that; I think you were puzzled too now...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D