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

[Tom Wijsman]

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

> Am 15.01.2014 17:20, schrieb 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:
> >>
> >>
> >> 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.
> >
> I'd say the clashes occurred because nobody mentioned at all what they
> are working on. Since people started using IN_PROGRESS to mean "I'm
> working on it", this shouldn't happen again.

Neither should it happen again if bugs get self-assigned; the point
here is that neither of both is discussed, agreed on or documented
properly. Therefore the clashes need further revising of the workflow.

> > 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.
> >
> There's nothing wrong with fixing/implementing something that nobody
> filed a bug about.

Sorry, consider the common case where a bug was filed but the commit
message does not refer to that bug. Also note that I am trying to refer
to the ChangeLog of Portage itself, not that of the ebuild; thus I
mean the commit messages for the Portage repo, not to the Portage tree.

> >>
> >> 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?
>
> Maybe, but I'd first see if the usage patterns converge to something
> that makes everyone happy.

The whole point of documenting it in a workflow is to make it converge;
if you instead leave things unclear or undocumented, you have no
guaranteed convergence and might even see a disconvergence.

It's already making people unhappy right now; because as it is
documented now, it is turned from the meaningful experience that the
previous Portage team had before to something that is meaningless. It
is a regression in checking the list of bugs that block the tracker, as
the states of the bugs no longer have a value as it is documented now.

If we change something about this, there should be a good reason 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.
> >
> > 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...
> >
>
> Sorry, I failed to properly read what you quoted.
>
> I think once you know that these other trackers exist, it's clear. If
> you want something added there, that's fine with me too.

We could add the sentence that I wrote earlier in the quote

    This does not mean to block the tracker for the next version.

but to avoid misreading we could write it up more positive and clear as

    These are other trackers than the next version tracker.

Optionally adding the redundant words "Note that" in front.

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