>> 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.
Hmm, however, that update had karma autopush set, and its threshold was reached. So what
exactly is the difference between maintainer asking to push and bodhi autokarma asking to
push? I assume they should behave exactly the same. Maybe autokarma push was not
triggered, or delayed for some reason? We need to find the difference and define that
condition more precisely, or fix a bug somewhere, else it's quite likely we'll
have a similar problem in the future.
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.
OK. I was just trying to point out that there needs to be about 1-2 day period (releng
knows best) between the 0 day push and the actual announcement. Maybe that's why we
usually have 4 days between Go and the announcement? I don't know whether there's
a releng process for it or not, but since QA wants to track 0 day updates more reliably,
it would make sense to also have a similar process in releng space to ensure the updates
are ready for everyone when the announcement goes out. I'd like to avoid the
system-upgrade sad story next time.