I've created a topic on Fedora Discussion for this ticket.

Please keep this ticket focused. Discuss there, and record votes and decisions here. Thanks!

As Cloud has not been an official Edition for several years and there is no plan established for reviving it, I've been asked to drop the Edition branding from it.

This has not been true. There is a plan. @davdunc made a Change proposal some time ago, however @bcotton veto'd the Change submission for F36, so it's targeted for F37. The Cloud WG has been working on this since the issue was brought up during F35 development.

I'm actually quite annoyed here, because this is a ton of needless paperwork. Dropping Edition in F36 only to restore it again in F37 is quite pointless. Not to mention Fedora Cloud is the Edition people see in Cloud providers, and if we're really about the cloud(tm), it should be front and center.

(Sidebar, I'm not commenting on Discourse for this ticket, because it doesn't make sense to do that.)

• Keep the branding subpackages and simply drop the word "Edition" so that the display text reads simply "Fedora Cloud" instead of "Fedora Cloud Edition"

+1

• Retire the cloud-specific branding and have it simply referred to as "Fedora"

-1

• Obsolete the cloud-specific branding by Fedora Server branding and have it refer to itself as "Fedora Server".

-1

As Cloud has not been an official Edition for several years and there is no plan established for reviving it, I've been asked to drop the Edition branding from it.

This seems highly opinionated and exclusive and I don't find that helpful one bit. I agree with Neal in that this is not accurate, but i also find it targeted as this has been much discussed with plans and retrospectives and has been announced in multiple channels.

[. . .]

(Sidebar, I'm not commenting on Discourse for this ticket, because it doesn't make sense to do that.)

I did comment on the discussion, but I agree with Neal's assessment here. Starting that thread made me feel like there was an attempt to escalate the rhetoric around this topic.

Also, @bcotton didn't veto it. He found that the policy made it a system-wide change instead of a local change and we didn't have a precedent for reestablishing vs. establishing an edition.

So, I don't mind one way or the other how this is decided, provided that if we are going to make ANY change at all, we should do it prior to entering Beta freeze... today.

@sgallagh If there is something to be done, then I am in favor of dropping "edition" in the same way that @bcotton voted. I think that's a reasonable request.

I admire Stephen's optimism in seeking a quick decision, but I notice after a week that I'm the only Council member who voted, and I'm not even a full member, so I don't think we can call this "decided".

That said, if the Cloud SIG wanted to proceed with option 1 (simply drop the word "Edition"), they wouldn't need to wait for a Council vote to do that.

The lack of response here suggests to me that the general consensus is "don't change anything for F36".

Proposal:

This has been this way for many releases (and probably should have been caught by the Council earlier). Since the Cloud WG intends to re-propose Fedora Cloud Edition, any change for F36 is likely to be switched back again for F37, with little practical benefit for the extra work, churn, and possible additional community confusion. Therefore, the Council asks QA to please waive this blocker for F36.

We aren't asking for a permanent waiver. If for some reason the Edition proposal doesn't come together for F37, we will re-evaluate.

Council, please vote. We'd like a formal consensus here, just so things are clear. That means three +1 votes and no -1 votes in the voting time period, which let's make by the end of the day Friday for this.

@bcotton I think as program manager you have a full vote on this particular issue.

+1 from me.

+1

+1

+1

On Wed, Mar 2, 2022, 1:53 PM Alberto Rodriguez Sanchez pagure@pagure.io
wrote:

bt0dotninja added a new comment to an issue you are following:
+1

To reply, visit the link below or just reply to this email
https://pagure.io/Fedora-Council/tickets/issue/389

+1

With a vote of +5,0,-0 the Council approves waiving this bug for Fedora Linux 36.

Just wanted to note this so it's on record here: I pointed out to @bcotton that, AFAICS, the Council does not actually have any formal power to waive blockers in this way. We decided the best way forward would be to give it that power, so Ben drafted a proposal which is under review. I'm bringing it up in meetings so people are aware and can object if they want to; so far nobody has. We'll plan to apply the change and therefore give force to the waiver vote by Thursday if nobody does object.

I thought I was careful in wording the proposal before, but maybe not enough, so let me emphasize:

Therefore, the Council asks QA to please waive this blocker for F36.

... we're not attempting to directly reach into the QA team process and meddle with things. I don't particularly care about the details by which the QA team responds to the request as long as it is reasonable. If that's make a new specific policy, sure. :)

In order to be careful about precedent, though: from the Council charter:

{The Council's] primary role is to identify the short, medium, and long term goals of the Fedora community and to organize and enable the project to best achieve them. This is done in consultation with the entire Fedora community through transparent, public discussion.

It's the Council's responsibility to make sure that all of our processes, including blocker bugs, are serving the established community goals. Correspondingly, in a case (now theoretical) that some process is not so serving, we have the formal power to "organize and enable" to address that issue. Also:

The Counci [...] is responsible for final arbitration of complaints related to project policies and for settling disputes escalated from other committees or subgroups

... and while I think we're not at the level of "dispute" here (I certainly hope not), it is definitely the case that were there to be a dispute between QA and another Fedora team over blockers which could not be amicably resolved without intervention, the Council would have both the responsibility and formal power to decide on a resolution — which might include waiving blockers.

Again, I don't think we're anywhere near that here, and I further think that the Council meddling at that level would require extraordinary circumstances in practice, and require us to generally be in a theoretical problematic situation with QA team functioning which we aren't. But, I do think that it's important to note that if such a situation would ever come up, the Council is able to act.

The problem there is, QA cannot arbitrarily waive blockers either. For a start, as I have to keep reminding folks, the blocker process is supposedly a collaboration between QA, releng and devel; it is not owned solely by QA. Secondly, the process for waiving blockers is quite specific: it requires in the first instance that the bug be either "proposed as blockers 5 days or fewer before the scheduled Go_No_Go_Meeting for a milestone release" or not "practical to fix within a reasonable time frame for the release to be made". This bug is clearly neither: it was proposed months ago, and fixing it requires a single sed command. There is no sustainable justification for the bug to be waived under existing processes.

I agree that Council has the roles you mention, but neither of those roles fits particularly well here. It's not like there's a substantial and ongoing problem with the blocker process, or (as you say) a "dispute" occurring between the groups that steward the blocker process and some other group, which has been raised to Council level.

Thanks @adamwill -- I think my "for the record" is recorded. I'll take the rest of my reply to Ben's proposal on the test list.

Just to close this out, since nobody objected to the new policy proposal, I implemented it and pushed the bug out to F37.

Thanks again @adamwill!