12:50 p.m.
## 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-iden...
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
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2:45 p.m.
New subject: Proposal: Explicitly allow Council to waive Edition
self-identification
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-iden...
> 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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
4:33 p.m.
New subject: Proposal: Explicitly allow Council to waive Edition
self-identification
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6:46 p.m.
New subject: Proposal: Explicitly allow Council to waive Edition
self-identification
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"...
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
3:04 p.m.
New subject: Proposal: Explicitly allow Council to waive Edition
self-identification
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.
:)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:11 a.m.
On Mon, Mar 14, 2022 at 5:33 PM Matthew Miller <mattdm(a)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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
11:28 a.m.
New subject: Proposal: Explicitly allow Council to waive Edition
self-identification
On Tue, 2022-03-15 at 08:11 -0400, Ben Cotton wrote:
On Mon, Mar 14, 2022 at 5:33 PM Matthew Miller
<mattdm(a)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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
11:54 a.m.
New subject: Proposal: Explicitly allow Council to waive Edition
self-identification
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-iden...
> 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
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
759
days inactive
776
days old
7 comments
3 participants
participants (3)
-
Adam Williamson -
Ben Cotton -
Matthew Miller