Fedora 13 Release Candidate Phase

Rakesh Pandit rakesh.pandit at gmail.com
Fri May 14 07:23:39 UTC 2010

On 14 May 2010 09:50, Matt McCutchen wrote:
> On Fri, 2010-05-14 at 09:31 +0530, Rakesh Pandit wrote:
>> On 14 May 2010 06:42, Josh Boyer wrote:
>> > On Thu, May 13, 2010 at 11:23:10PM +0100, Adam Williamson wrote:
>> >>Really? I don't think there's *that* many cases where a negative piece
>> >>of karma is filed between the submission and the push which you'd want
>> >>to ignore. And even in the rare cases when that happens, if we warn or
>> >>even unsubmit the update, it's not like you can't do anything about it.
>> >>If we make it a warning...ignore the warning. If we make it withdraw the
>> >>update...just submit it again. I'm having a hard time seeing that fall
>> >>apart.
>> I don't know about real statistics of these kinds of reports, but In
>> case it is really a big number I would suggest to increase the gap
>> between submitting so that maintainer gets a week or few more days to
>> decide (reach to his mail and take a decision, whether to un-submit
>> the push).
> The maintainer can already decide when to submit for stable based on the
> total amount of testing he/she thinks the update needs before it is
> pushed.  Arbitrarily lengthening the push delay would just make the
> process less efficient.  If what you are after is a minimum time between
> the testing push and stable push, that is a policy question and should
> be considered as such.
> The issue Bernie raised was simply that if a negative report that merits
> stopping the update happens to come in while we still have the option to
> cancel the push, we might as well cancel it.

What I meant was (suggestion):

No change in normal process. Just 2-3 days extra between this
particular case in which a nack (-ve karma) is received between
maintainer requesting a push for stable and rel-eng submitting it. It
will prevent `race condition` where say maintainer wants to pull it
back but before he does so it is pushed.

Rakesh Pandit
freedom, friends, features, first

More information about the devel mailing list