motu-release process (was: Re: Sponsorship Queue Process)

Andrew SB a.starr.b at gmail.com
Fri Aug 28 15:34:27 BST 2009


On Thu, Aug 27, 2009 at 2:39 PM, Stefan
Potyra<stefan.potyra at informatik.uni-erlangen.de> wrote:
> Hi Brian,
>
> Am Thursday 27 August 2009 19:59:49 schrieb Brian Murray:
> [..]
>>
>> 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.
>
> I think bug statuses meaning the same thing for each queue would be ideal. For
> motu-release, we use confirmed to denote that a FFe is granted, and invalid
> to mean it was denied. FFe bugs usually start at new.
>
> For the interpretation of FFe's this seems sane to me (it's a new request,
> which turns out to be either invalid or gets confirmed by motu-release).
> However (apart from the occasional bug starting at confirmed) sometimes
> motu-release is subscribed to existing bugs. Exactly there this scheme breaks
> (the bug is of course _not_ invalid, just because the FFe was denied as
> motu-release deems that a targeted fix is more appropriate than a new
> upstream version).

Perhaps we should be using release targeting for cases where
motu-release is subscribed to existing bugs?

Adding a Karmic task for the FFe would allow for the exception to be
rejected without invalidating the entire bug if the change wasn't
deemed as appropriate. This seems to be a logical extension of the SRU
policy.

>
> Basically what I need from FFe bugs is a way to
> * see which FFe's are granted already (I don't regular look at these)
> * see which FFe's are still in my queue
>
> Any good idea how to improve our usage of bug statuses?
>
> Cheers,
>    Stefan.
>

- Andrew Starr-Bochicchio



More information about the ubuntu-devel mailing list