Re: Proposal: Explicitly allow Council to waive Edition self-identification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux