On 11/20/2015 03:56 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-e00b75e39f
dnf-plugin-system-upgrade-0.7.0-1.fc22 had enough karma for stable
on
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.
--
Kalev
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
