On Fri, Aug 11, 2017 at 12:51 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
I tried to discuss this topic in the past wrt AcceptedPreviousRelease, and I didn't receive many responses from relevant people. From what I did receive, I created this description (part of the official SOP, so it should be "in production"):
On Thu, 2017-08-10 at 10:59 +0200, Jan Kurik wrote:
> Thanks Adam for putting this together. I am definitely+1 to extend the
> Blocker bug process with your proposal.
>
> And there is one more topic related to this: how we should deal with
> 0day bugs found at the last moment before release ? Should not we have
> a statement for Accepted0Day and AcceptedPreviousRelease blockers
> saying that such bugs need to be verified and have enough karma before
> relevant Go/No-Go meeting ? My question is base on the experience we
> made during F26 release cycle, when we stopped already running
> mirroring of a release as we realized the 0day fix will not be ready
> at the release day. Having such a statement (and follow it) might save
> the effort especially RelEng is putting into the release activities
> after Go/No-Go meeting.
I think we could certainly stand to clarify the exact requirements
around Accepted0Day and AcceptedPreviousRelease blockers, yes. AFAIK
all we have for now is this in the blocker process SOP page:
"Accepted0Day is used for cases where the fix does not need to appear
in the final frozen release, but must be available as an update on
release day. AcceptedPreviousRelease is used for cases where the fix
must appear as an update for one or more stable releases."
And we're definitely missing some written-down policy about exactly
when the updates must be in exactly what state. I think we can do that
separately from this, though. I've got a lot on my plate ATM so it'd be
great if someone else could do this draft - perhaps you or Kamil (as I
know he's been interested in the question before)?
It might seem that this only discusses when to close AcceptedPreviousRelease bugs. However, having all blocker bugs closed is a prerequisite to voting "Go". So this is effectively a policy of how to handle AcceptedPreviousRelease blockers state during Go/NoGo. The key sentence describing the required state is:
"Only when it is guaranteed that MirrorManager refers only to the push
containing the fixed package or newer pushes, we should mark this bug as
CLOSED ERRATA.
"
And track-previous-release-blocker.py script implements that (it's quite tedious to check that manually). I guess we could use the same approach (and the same script) even for Accepted0Day. I'm not exactly sure how 'updates' repo is handled before Go, whether some people with older repos can get older metadata not containing the required fix. If it is guaranteed that 'updates' repo on release day is always up-to-day for all users (i.e. it's the very push to that repo, no older metadata references are in repomd.xml), it's even easier to check the state - just make sure the fix is in updates-pending tag and we're good to go.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
