From: Mart Raudsepp <leio@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [POLICY] Keywording/Stabilizing Bug Assignment Policy
Date: Wed, 18 Apr 2007 16:59:02 +0300 [thread overview]
Message-ID: <1176904742.5868.19.camel@localhost> (raw)
In-Reply-To: <4625187A.4060403@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 3712 bytes --]
On Tue, 2007-04-17 at 14:56 -0400, Doug Goldstein wrote:
> I would like to take this time to note and re-affirm the proper bug
> assignment policy and have it noted somewhere officially in Gentoo Policy.
>
> Bugs that are created for the purpose of getting arches to keyword or
> stabilize a particular package should initially be assigned to the
> herd/maintainer of said package with all requested arches being CCed.
> Once all but the last arch has keyworded said package, it is acceptable
> and proper for a bug wrangler and/or maintainer/herd to re-assign the
> bug to the last remaining arch and they remove that arch from CC. They
> should add their herd/maintainer to the CC of the bug.
This has various possible issues. Let me list some:
a) The bug moves from saved searches of "bugs assigned to my team" to
"bugs my team is CC'ed to" - two saved searches that big teams have to
differentiate bugs to their packages with bugs to someone elses packages
that are requesting comments from the team. That moving of bug to a
different list then happens through the actions of a third party
b) Similarly, then keywording/stable bugs for a team are mixed up
between "assigned directly to our team" and "our team is on the CC
list", so there is no good overview (seeing both types at once could
mean a bug list of 400, for example instead of 200 and 200)
c) Arch teams have to look at both CC and assignee lists of them to find
stabling bugs, while initial keywording bugs (by users of that arch) are
usually always assigned directly to them. Having marking stable bugs as
both assigned and CC'ed (depending on if they are last or not) means
they need to look at all at once to grasp everything. I don't know if
this is a potential problem or not as I'm not a member of any arch teams
at this point
d) (I think) The slacking arch gets a bug resolved count into GWN stats
if they close the bug with them being the assignee (due to the
reassignment as proposed) instead of the team managing that package. The
quicker arches should have that benefit if any, not the last one.
These are some of the things that bother me about this proposed policy,
as a member of a big team with hundreds of open bugs - and not
necessarily said team(s).
> Once the last remaining arch has completed the bug, it is up to them to
> close it. They know it's up to them to close it since the bug is
> assigned directly to them.
In practice the last arch in CC list already does that almost always if
there are no other raised issues on the bug, so that is not a problem.
> This helps keep bugzilla tidy and makes it easy to identify
> stabilization/keywording requests which are a priority for that arch to
> take care of.
I wouldn't automatically consider stabilization bugs that have one last
arch to do the job be more important than bugs that have multiple arches
to take care of still.
This is usually only important for cleanup of ebuilds, and that's
cosmetical, while usually perceived very bothering by the maintaining
team.
I think the idea in a subthread about special keywords for these two
types of things would be great, as then we can create saved searches
that either include only bugs with one or both of these keywords, or
that exclude bugs with any of these keywords. I'm not sure if this being
a keyword, as opposed to a different bugzilla property is the best,
though, especially when it comes to having people actually use it
consistently. Perhaps a javascript button would help then, akin to the
helper for arch CC'ing.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-04-18 14:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-17 18:56 [gentoo-dev] [POLICY] Keywording/Stabilizing Bug Assignment Policy Doug Goldstein
2007-04-17 19:17 ` Ciaran McCreesh
2007-04-17 19:19 ` Ned Ludd
2007-04-17 19:36 ` Doug Goldstein
2007-04-17 19:57 ` Sune Kloppenborg Jeppesen
2007-04-17 19:50 ` [gentoo-dev] Re: [gentoo-core] " Stefan Schweizer
2007-04-17 20:06 ` Bryan Østergaard
2007-04-17 20:06 ` [gentoo-dev] " Alin Năstac
2007-04-17 20:25 ` [gentoo-dev] Re: [gentoo-core] " Chris Gianelloni
2007-04-17 22:36 ` Vlastimil Babka
2007-04-18 13:39 ` Jim Ramsay
2007-04-18 13:57 ` Chris Gianelloni
2007-04-18 15:14 ` Jim Ramsay
2007-05-27 10:23 ` [gentoo-dev] STABLEREQ/KEYWORDREQ Keywords in bugzilla Vlastimil Babka
2007-05-27 10:39 ` Robin H. Johnson
2007-05-27 11:06 ` Vlastimil Babka
2007-04-17 20:07 ` [gentoo-dev] [POLICY] Keywording/Stabilizing Bug Assignment Policy Samuli Suominen
2007-04-18 13:59 ` Mart Raudsepp [this message]
2007-04-20 23:33 ` [gentoo-dev] " Ryan Hill
2007-04-21 2:55 ` Chris Gianelloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1176904742.5868.19.camel@localhost \
--to=leio@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox