Re: [gentoo-dev] changes to tested bugzilla keyword proposal

[Jeroen Roovers <jer@gentoo.org>]

On Wed, 9 Jan 2013 18:39:09 +0200
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 9 January 2013 18:17, Vicente Olivert Riera <peratu@carrosses.com>
> > some devs and I were talking about the fact that TESTED bugzilla
> > keyword may need a change on his description, or, maybe it's needed
> > to create new TESTED_${ARCH} keywords.
> >
> > Personally, I was using TESTED keyword when an ebuild was tested on
> > every CC'ed arch, but there are some discrepancy about that, so we
> > decided to discuss this topic on gentoo-dev@
> >
> > What do you think? What about to create a TESTED_${ARCH} keyword for
> > every arch?

Backgrounder:

Until 2006, the TESTED keyword was used mainly by the amd64 team, when there
was a bit of a race to get everything keyworded for amd64 that was already
keyworded for x86.[1] Since then it was disused, until peratu picked it up recently.

One problem with TESTED is that it's ambiguous. Even if an arch tester has
covered all affected arches, someone might add an extra arch after TESTED got
added, and then TESTED would have to be removed again. One solution is to
remove it or never use it, and another is to split it out into TESTED_$arch,
which as Markos says, might get the Keywords field a bit crowded.

Another problem with TESTED is that anyone can add it or remove it. Looking
through the comments or the bug report's History then becomes a necessity once
again, which kind of evades the whole purpose of having a single place to look
up what arches a package was already tested on.

Also, the comments might reveal information that might stop you from
stabilising the package, like a second arch tester contesting that in some
configuration, the package doesn't work as expected or causes a regression, so
this makes TESTED ambiguous in quite a different way yet again, and the
Keywords field offers no clue to this. There would at least have to be a policy
where arch testers can contest the keyword by removing it again, but even so
the arch developer could be acting on a single reading of Keywords.

> The "Keywords" field will end up huge if every CC'd arch uses it's own
> TESTED_$ARCH keyword. Although only x86 and amd64 have arch testers
> nowadays. Would it be preferred to have a list of checkboxes for every
> CC'd arch, and Arch Testers have privileges to select them if a
> package works for their arch? This would eliminate the "works on
> $arch" comments that flood the stabilization bugs.

You would still get those comments posted and messages sent upon changes to the
bug report, unless you somehow switched that off internally or through your
Bugzilla mail preferences or mail filters.

A lot clearer than a single text field littered with keywords would be some
tick boxes, indeed. In fact, it makes me wonder why we use a half-obscured list
in a select field for adding/removing arch teams now.


Regards,
     jer


[1] Back in the day, it was common to assign keywording/stabilisation bugs to
	arch teams, instead of to its maintainers as it is done now. This turned out
	problematic in cases where another arch was added to the bug report after
	the fact - the maintainers would have to become Assignee and the Assignee
	arch would be placed in the CC list. One bug wrangler even had the habit of
	switching maintainers/arch teams when the arch team turned out to be
	"slacking", which would then involve the samek awkwardness in reassigning
	the bug report back to its maintainers upon its resolution.