#1126 Need a procedure for tracking FESCo release blockers
Closed None Opened 10 years ago by toshio.

= phenomenon =

adamw noted that FESCo decisions about changes that must happen to packages in time for a release sometimes fall through the cracks. He noticed that https://fedorahosted.org/fesco/ticket/1115 hadn't been applied yet to the package, for instance: https://bugzilla.redhat.com/show_bug.cgi?id=975214

He suggested that we should have a way of tracking things that need to block release.

= implementation recommendation =

I'll make a proposal here that adamw has okay'd as meeting the minimum requirements for this. He did mention that if we'd like to not hinge on the current release blocker process, that's perfectly fine with him too :-)

Proposal:

  • Expand the release blocking criteria to include bugs/issues that fesco thinks need to be addressed for the release.
  • FESCo needs to file bugs and make them block the (Alpha,Beta,Final)Blocker tracking bugs in bugzilla to get them on the release blocker list.

Examples of things that FESCo might file bugs for would include bugs required to implement Features, changes to packages that FESCo has mandated must happen for the next release, changes to security policy, etc.


As I won't be able to attend FESCo meeting today:

+1 to the proposal above.

This was discussed at the 2013-06-19 fesco meeting where we agreed to this policy.

Is there anywhere we need to record it? or just add it to the blocker bug info?

Well, if you want to take advantage of the release criteria / validation / blocker process to track FESCo-mandated 'blocking' issues, what I'd expect to happen next is someone should send a proposed criterion to the test@ list. There are dozens of such 'criteria proposal' mails in the test@ archives to serve as an example of what we'd be looking for. Just something like "I propose the criterion 'All issues required by FESCo to be addressed before the milestone is released must be addressed' be added to the Alpha criteria', with a reference to this ticket. Something like that.

The way the process works is that only bugs that violate the release criteria are accepted as blocker bugs, so for FESCo blockers to be accepted as release blockers via this process, there needs to be a criterion. Once the criterion exists, everything just slots nicely into place: when FESCo wants a bug to be a blocker all you have to do is propose it as one and refer to the meeting log or ticket or whatever which records the FESCo vote that the bug must block the release.

Proposal sent. Ready to see flames. ;)

I guess we can close this now unless there's some problem adopting it, in which case we can reopen.

Login to comment on this ticket.

Metadata