## Proposal
Modify the "Edition self-identification" criterion to explicitly give the Fedora Council the ability to waive the blocker status of bugs that violate this criterion. Specifically, append the following to https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Self-identif...
The Fedora Council, as the body that defines Editions, may vote to waive this criterion at its discretion through its regular decision-making process.
I included "as the body that defines Edition" to make it clear that the Council's ability to waive this criterion follows from its ownership of what an Edition is and not as a broad "the Council can waive arbitrary criteria" statement.
The reason I said "regular decision-making process" is to indicate that waiving a blocker under this criterion requires a normal ticket vote[1], not a policy change[2].
## Context
During F35, Adam discovered that our Cloud deliverables were calling themselves an Edition when they are not. This violates the "Edition self-identifications" Final release criterion.
We waived this for F35 under the "late blocker exception". The Cloud SIG is working to re-Editionify Cloud, but that won't happen for F36. The Council agreed to waive this[3], but we don't have an explicit mechanism to allow this. Hence, the proposal above.
[1] https://docs.fedoraproject.org/en-US/council/#_making_decisions [2] https://docs.fedoraproject.org/en-US/council/policy/policy-change-policy/ [3] https://pagure.io/Fedora-Council/tickets/issue/389#comment-785482
On Fri, 2022-03-11 at 13:50 -0500, Ben Cotton wrote:
## Proposal
Modify the "Edition self-identification" criterion to explicitly give the Fedora Council the ability to waive the blocker status of bugs that violate this criterion. Specifically, append the following to https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Self-identif...
The Fedora Council, as the body that defines Editions, may vote to waive this criterion at its discretion through its regular decision-making process.
I included "as the body that defines Edition" to make it clear that the Council's ability to waive this criterion follows from its ownership of what an Edition is and not as a broad "the Council can waive arbitrary criteria" statement.
The reason I said "regular decision-making process" is to indicate that waiving a blocker under this criterion requires a normal ticket vote[1], not a policy change[2].
## Context
During F35, Adam discovered that our Cloud deliverables were calling themselves an Edition when they are not. This violates the "Edition self-identifications" Final release criterion.
We waived this for F35 under the "late blocker exception". The Cloud SIG is working to re-Editionify Cloud, but that won't happen for F36. The Council agreed to waive this[3], but we don't have an explicit mechanism to allow this. Hence, the proposal above.
[1] https://docs.fedoraproject.org/en-US/council/#_making_decisions [2] https://docs.fedoraproject.org/en-US/council/policy/policy-change-policy/ [3] https://pagure.io/Fedora-Council/tickets/issue/389#comment-785482
I'm +1 to this; it makes sense for me that Council should be able to veto/waive blocker decisions in this specific context, I just wanted there to be a proper mechanism for it. This seems like a reasonable way to achieve that.
On Fri, Mar 11, 2022 at 12:45:05PM -0800, Adam Williamson wrote:
I'm +1 to this; it makes sense for me that Council should be able to veto/waive blocker decisions in this specific context, I just wanted there to be a proper mechanism for it. This seems like a reasonable way to achieve that.
First, I want to (in complete non-ironic sincerity) express appreciation to all of y'all process-oriented folks who make sure this stuff stays on track.
Continuing from https://pagure.io/Fedora-Council/tickets/issue/389#comment-785815...
I suppose as an engineering collaboration (releng, devel, qa...) it may have been better for us to direct this at all of those teams, or maybe FESCo.
FESCo has a "make this a blocker" button... I kind of feel an itch for a generalized "sometimes stuff comes up" lever that goes the _other_ direction, rather than a very specific carve-out.
We wouldn't be here if I (well, the Council, but I'll go ahead and say specifically _me_) had made sure we'd done the proper followup around Cloud "de-editioning" several years ago, and I don't think there's likely to be a case where this new policy is actually ever used again — if there is, that'd signal another failure.
On Mon, 2022-03-14 at 17:33 -0400, Matthew Miller wrote:
On Fri, Mar 11, 2022 at 12:45:05PM -0800, Adam Williamson wrote:
I'm +1 to this; it makes sense for me that Council should be able to veto/waive blocker decisions in this specific context, I just wanted there to be a proper mechanism for it. This seems like a reasonable way to achieve that.
First, I want to (in complete non-ironic sincerity) express appreciation to all of y'all process-oriented folks who make sure this stuff stays on track.
Continuing from https://pagure.io/Fedora-Council/tickets/issue/389#comment-785815...
I suppose as an engineering collaboration (releng, devel, qa...) it may have been better for us to direct this at all of those teams, or maybe FESCo.
FESCo has a "make this a blocker" button... I kind of feel an itch for a generalized "sometimes stuff comes up" lever that goes the _other_ direction, rather than a very specific carve-out.
I feel pretty strongly the opposite on that one. Ben pre-empted me on IRC by already suggesting this approach (which I'm fine with), but before he had sketched out the specific approach, I was going to specifically suggest *NOT* giving Council (or anybody else) a "this isn't a blocker" rubber stamp. To me there's a big difference between a "this is a blocker" button and a "this isn't a blocker" button. The temptation to overuse the latter just to get releases done on time would, I think, be entirely too great.
We wouldn't be here if I (well, the Council, but I'll go ahead and say specifically _me_) had made sure we'd done the proper followup around Cloud "de-editioning" several years ago, and I don't think there's likely to be a case where this new policy is actually ever used again — if there is, that'd signal another failure.
It's hard to predict the future, but the larger point for me is there's a very strong justification for this specific carve-out. This specific criterion exists essentially to check a branding decision: the "Edition" wording is important and must be applied properly. As branding is explicitly a Council responsibility, it makes sense to me that we can say Council has the ability to make the judgment in a case like this that the branding concern isn't big enough to block on the bug.
It's much less clear to me that Council or FESCo or anybody else should be able to just declare that *any* bug shouldn't be a blocker. There isn't that specific justification about branding for most of the other criteria. It'd be consistent, for me, to extend the same mechanism to any other criteria that are exclusively backing branding concerns (if we have more, I don't recall off the top of my head), but it doesn't make much sense to me for us to say e.g. "the package manager must be able to install packages, unless Council/FESCo/somebody decides, hey, actually, no big deal, let's just ship it"...
On Mon, Mar 14, 2022 at 04:46:00PM -0700, Adam Williamson wrote:
I feel pretty strongly the opposite on that one. Ben pre-empted me on IRC by already suggesting this approach (which I'm fine with), but before he had sketched out the specific approach, I was going to specifically suggest *NOT* giving Council (or anybody else) a "this isn't a blocker" rubber stamp. To me there's a big difference between a "this is a blocker" button and a "this isn't a blocker" button. The temptation to overuse the latter just to get releases done on time would, I think, be entirely too great.
Very possibly! I would certainly feel the temptation. This is why I said that it's good for me to listen to those of y'all who are good at process. :)
On Mon, Mar 14, 2022 at 5:33 PM Matthew Miller mattdm@fedoraproject.org wrote:
FESCo has a "make this a blocker" button... I kind of feel an itch for a generalized "sometimes stuff comes up" lever that goes the _other_ direction, rather than a very specific carve-out.
Like Adam, I fear we'd be too tempted to use it as a "YOLO, ship it!" button. It wouldn't happen right away, but slowly, we'd become more comfortable with waiving more things. I think there are more likely to be cases where we'd want to block on things (e.g. "wow, this bug will be really embarrassing when reviewers find it, but it doesn't actually violate any criteria") arbitrarily than cases where we'd wave. In the "this should be a blocker, actually" case, we can lean on FESCo to use their blocker power to apply it, so I don't think Council needs an explicit authority there. We already have exceptions to allow some blockers to be waived, and I think most of the ones we'd want to waive could be handled under those.
Also, as a group we're pretty good at word lawyering when we set our minds to it, so we can find ways to say "this bug does not violate a very specific interpretation of the criteria" if it comes down to it. :-)
We wouldn't be here if I (well, the Council, but I'll go ahead and say specifically _me_) had made sure we'd done the proper followup around Cloud "de-editioning" several years ago, and I don't think there's likely to be a case where this new policy is actually ever used again — if there is, that'd signal another failure.
At the risk of being too pedantic, I want to point out that this is not a new policy. The only reason we're having this discussion is because I was going to just make it happen but I asked Adam about his preferences on the mechanics of it. I argued (correctly, of course) that the Council always had this authority implicitly because it decides what is and is not an Edition. And I think that's why we saw no pushback on the list, in the QA meeting, or in the Blocker Review meeting. Everyone understands that this makes sense. But for the purposes of release criteria, it's better to be explicit than implicit.
We're not adding a new feature here. We're fixing a bug so that we get the expected behavior in an exceptional case.
On Tue, 2022-03-15 at 08:11 -0400, Ben Cotton wrote:
On Mon, Mar 14, 2022 at 5:33 PM Matthew Miller mattdm@fedoraproject.org wrote:
FESCo has a "make this a blocker" button... I kind of feel an itch for a generalized "sometimes stuff comes up" lever that goes the _other_ direction, rather than a very specific carve-out.
Like Adam, I fear we'd be too tempted to use it as a "YOLO, ship it!" button. It wouldn't happen right away, but slowly, we'd become more comfortable with waiving more things. I think there are more likely to be cases where we'd want to block on things (e.g. "wow, this bug will be really embarrassing when reviewers find it, but it doesn't actually violate any criteria") arbitrarily than cases where we'd wave. In the "this should be a blocker, actually" case, we can lean on FESCo to use their blocker power to apply it, so I don't think Council needs an explicit authority there. We already have exceptions to allow some blockers to be waived, and I think most of the ones we'd want to waive could be handled under those.
Also, as a group we're pretty good at word lawyering when we set our minds to it, so we can find ways to say "this bug does not violate a very specific interpretation of the criteria" if it comes down to it. :-)
And to expand on this a bit - I'd say that Council *does* have the power already, if it comes down to it, to say "we have decided that the release criteria should say XXX. Make it so." And I actually would prefer Council do *that* if it comes to it, than just be able to say "whatever the release criteria say, bug YYY is not a blocker". It seems somehow more transparent and in line with the goal of making consistent decisions to me.
On Fri, 2022-03-11 at 13:50 -0500, Ben Cotton wrote:
## Proposal
Modify the "Edition self-identification" criterion to explicitly give the Fedora Council the ability to waive the blocker status of bugs that violate this criterion. Specifically, append the following to https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Self-identif...
The Fedora Council, as the body that defines Editions, may vote to waive this criterion at its discretion through its regular decision-making process.
I included "as the body that defines Edition" to make it clear that the Council's ability to waive this criterion follows from its ownership of what an Edition is and not as a broad "the Council can waive arbitrary criteria" statement.
The reason I said "regular decision-making process" is to indicate that waiving a blocker under this criterion requires a normal ticket vote[1], not a policy change[2].
## Context
During F35, Adam discovered that our Cloud deliverables were calling themselves an Edition when they are not. This violates the "Edition self-identifications" Final release criterion.
We waived this for F35 under the "late blocker exception". The Cloud SIG is working to re-Editionify Cloud, but that won't happen for F36. The Council agreed to waive this[3], but we don't have an explicit mechanism to allow this. Hence, the proposal above.
[1] https://docs.fedoraproject.org/en-US/council/#_making_decisions [2] https://docs.fedoraproject.org/en-US/council/policy/policy-change-policy/ [3] https://pagure.io/Fedora-Council/tickets/issue/389#comment-785482
So nobody has objected to this, and we've brought it up in QA and blocker review meetings, and in the Council thread; I'm gonna go ahead and implement it so we can apply the waiver to the bug report. Thanks for the proposal, Ben.
-
Adam Williamson -
Ben Cotton -
Matthew Miller