[gentoo-dev] changes to tested bugzilla keyword proposal

[gentoo-dev] changes to tested bugzilla keyword proposal

[Vicente Olivert Riera]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone :-)

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?

Best regards,
- -- 
*************************
Vicente Olivert Riera
peratu@carrosses.com
ID GnuPG: 5AE9E7B2E9BBCBA8
*************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDtmAIACgkQWunnsum7y6i1GQCdE60IS5OjVYjBn6y9YFU5QhhC
hKsAn3mPVPclED+CP8db+inhhQmfFaAT
=W+jm
-----END PGP SIGNATURE-----

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

[Markos Chandras]

On 9 January 2013 18:17, Vicente Olivert Riera <peratu@carrosses.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello everyone :-)
>
> 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?
>
> Best regards,
> - --
> *************************
> Vicente Olivert Riera
> peratu@carrosses.com
> ID GnuPG: 5AE9E7B2E9BBCBA8
> *************************
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlDtmAIACgkQWunnsum7y6i1GQCdE60IS5OjVYjBn6y9YFU5QhhC
> hKsAn3mPVPclED+CP8db+inhhQmfFaAT
> =W+jm
> -----END PGP SIGNATURE-----
>

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.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

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

[Jeroen Roovers]

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.

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

[Rich Freeman]

On Wed, Jan 9, 2013 at 12:02 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> 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.

Agree - mostly legacy (perhaps due to previous limitations in bugzilla?).

Non-arch-specific tested/stable keywords are useless IMHO.  Their main
purpose is for bug filtering.  The concept is that you have a large
team of arch testers who can do the testing, and a smaller team of
devs with commit access who search for bugs with the appropriate marks
and do the commit/close (often with little testing of their own).

When only amd64 was doing it the single keyword worked fine.

Do we have enough ATs around that this is even worth having any
longer?  I know that whenever I run my keyworded-but-still-amd64-cc
query it is pretty rare for stuff to come up.  Years ago that was the
arch team bread-and-butter.

Rich

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Wed, 9 Jan 2013 18:02:01 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

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


https://bugs.gentoo.org/213514


On Sat, 01 Mar 2008 09:24:36 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On keywording/stabilizing, Bugzilla has a flags feature that might be used to 
> track what has been tested where.
>
> Flags have three states: +, -, and ?.  + and - are obvious, and ? is a
> request. So imagine having a "x86 tested" flag that the maintainer sets to
> "?" to request stabilization of their package.  An email is sent to the arch
> alias notifying them of the request.  The arch tester tests it out and sets
> the flag to + or - depending on their results.  The arch dev stabilizes the
> package as normal.
> 
> If we added a "Keyword/Stable Request" component to the "Gentoo Linux"
> product we could also have it dependent on that, so only bugs in that
> component would display the flags.  We can also make it so only people with
> editbugs privileges can request or set flags.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Fri, Feb 1, 2013 at 12:37 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
>>
>> If we added a "Keyword/Stable Request" component to the "Gentoo Linux"
>> product we could also have it dependent on that, so only bugs in that
>> component would display the flags.

You'd need to include security bugs as well at the very least as they
almost always include keyword changes.

Are there any issues with changing the product/component on existing
bugs?  I could see things turn into keyword requests which didn't
start out as such.

>> We can also make it so only people with
>> editbugs privileges can request or set flags.

++

Rich

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Fri, 1 Feb 2013 06:15:32 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Feb 1, 2013 at 12:37 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> >>
> >> If we added a "Keyword/Stable Request" component to the "Gentoo Linux"
> >> product we could also have it dependent on that, so only bugs in that
> >> component would display the flags.
> 
> You'd need to include security bugs as well at the very least as they
> almost always include keyword changes.

Good catch.

> Are there any issues with changing the product/component on existing
> bugs?  I could see things turn into keyword requests which didn't
> start out as such.

The message I quoted was from 2008.  We've added a Keywording and
Stabilization component since then so we're halfway there already.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On Sun, 3 Feb 2013 01:41:00 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Fri, 1 Feb 2013 06:15:32 -0500
> Rich Freeman <rich0@gentoo.org> wrote:

> > Are there any issues with changing the product/component on existing
> > bugs?  I could see things turn into keyword requests which didn't
> > start out as such.
> 
> The message I quoted was from 2008.  We've added a Keywording and
> Stabilization component since then so we're halfway there already.

I misread that.  I don't think there would be any issues, though I really don't
know.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]