On 11/20/2015 03:56 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On 11/20/2015 07:16 AM, Kamil Paral wrote:
>> The biggest issue is this, I think. We probably need to encode
>> "Special Blockers" into the Go/No-Go process. I don't think that
>> assurance that it will be fixed on time is necessarily good
>> enough. Particularly given the time that it takes stable updates
>> to make it to the mirrors, I'd say that we probably want to say
>> that any such special blockers have to be queued for stable
>> before the Go/No-Go decision is made. (This may in some cases
>> mean *during* the Go/No-Go meeting, of course.)
> Well, here's our latest mess-up:
> dnf-plugin-system-upgrade-0.7.0-1.fc22 had enough karma for stable
Oct 29, which was Go/No-Go day. Therefore it was considered "resolved".
"Had enough karma" != queued for stable. When I say "queued for
stable", I mean that it needs to be "submitted for stable" and
awaiting a push (if not already pushed). According to the history on
that bug, it was not actually submitted for stable until November 2nd.
That would have failed my criterion above, since that was after Go/No-Go.
Yup, I think "queued for stable" is the right thing to require here.
Releng always does a 0 day push; we just need to ensure during the
blocker review process that things that need to be included in that push
are actually queued for stable.
That should be enough for all practical purposes. I mean, releng's 0 day
push may fail of course or take longer than expected, but I don't think
that needs to be tracked with the blocker review process. Releng is
going to be painfully aware if their pushes are failing anyway and
working as fast as they can to fix them.