Sponsorship Queue Process

[Brian Murray]

On Fri, Aug 21, 2009 at 09:46:58AM +0200, Daniel Holbach wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian Murray wrote:
> > I was looking at some documentation regarding the sponsorship queue[1]
> > the other day and noticed that it doesn't mention the Triaged status at
> > all.  I understand that people requesting sponsorship wouldn't
> > necessarily be able to set the Triaged status but the documentation
> > might lead one to believe that a bug must be in Confirmed status for it
> > to be sponsored and that moving bugs from Triaged to Confirmed makes
> > sense.  It doesn't in this case and wanted to update the process
> > documentation to indicate that Confirmed or Triaged could be used by
> > people requesting sponsorship and that Triaged should be used by
> > sponsors.  Does that seem reasonable?
> 
> I look at the sponsoring queue almost every day and almost every bug
> status is used and I guess there's almost every time a proper
> justification for it.
> 
>  - "In Progress" because "getting the fix into Ubuntu" is still in
>    progress.
>  - "Confirmed" because the bug or the patch is confirmed to work.
>  - "Triaged" because the triage process is complete and the problem
>    well understood.
>  - "Fix Committed" because "a fix is available".
>  - "New" because "the fix has not been uploaded yet".
>  - etc.

From this I get the impression that the definition of each bug status
changes if the bug is in the sponsorship queue, which is exactly the
confusion I want to avoid.  The bug statuses should mean the same thing
as much as possible across the distribution to minimize the potential
for errors and misunderstanding. 

Kees mentioned that the security team uses "In Progress" to indicate
that a patch is ready for sponsorship.  This in conjunction with
subscribing the appropriate team makes the most sense to me.  

> It's my gut feeling that this is a result of mixing bug status with
> patch status and additionally having a team subscribed or unsubscribed
> being part of the process.

I think having a team subscribed or unsubscribed from a bug report is
a reasonable way to convey information about what is happening with the
bug report.  However, the fact that a team is subscribed to a bug
shouldn't affect the definition of other attributes of the bug report.

> Because I'm very pragmatic and don't like long wiki pages that regulate
> every imaginable case, I'd probably say "don't bother with the wiki
> page, let's hope that we use merge proposals for everything soon which
> are much much clearer", but I don't know how many people see this as I
> do. :-)

I too look forward to the day when merge proposals become the norm but I
still think it is sufficiently far off that we should sort out the
process for the sponsor's queue.  Additionally, the same issue of bug
statuses changing depending on whether a team is a subscribed or a
branch is attached could exist.  So why not sort it out now?

-- 
Brian Murray                                                 @ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090827/bddba62a/attachment-0002.pgp