Hi there! We agreed at today's QA meeting we agreed it'd be responsible to alert FESCo that, in our opinion, the Beta schedule is somewhat at risk, at this point.
Major issues include:
Modularity is still not fully implemented and testable; issues around repository configuration and mirrormanager are still being shored up. So we have not yet been able to test Modularity in any meaningful way at all.
FreeIPA still does not work at all and never has, this cycle. FreeIPA folks think they have a plan to get it working - at least to fix the problems they know about - but experience suggests that we should be prepared for the possibility of as-yet unforeseen issues beyond the problems we currently know about.
Composes were broken for a long time and have only recently started working again, so we haven't really had a lot of testing of many things that have landed in the last few weeks. There could well be blocker issues we just haven't got to yet in testing.
There's a whole arch we're supposed to be supporting as a primary arch for the first time - aarch64 - and we are still getting automated testing of it up and running. I'm not clear on how much manual testing it's had so far; @pwhalen might have a better idea. Note that the plan is to block on Server, which means we have a brand new arch blocking on FreeIPA, which hasn't worked even on x86_64 for months. We are currently waiting on RH IT to change a firewall configuration before we can actually get openQA testing on aarch64 running.
Put all that together, with the go/no-go date set for 2018-03-22, and I think it's fair to say there's a reasonable chance we're not going to hit that date. We figured it'd be good to flag this up to FESCo's attention.
Metadata Update from @jkurik: - Issue tagged with: meeting
Are there things we could do better next cycle to avoid the "composes were broken for a long time" issue?
Since modularity is now an add on, I'm inclined to think that it should not be a release blocker. Thoughts?
It's a Council Objective. I think the add-on repo makes it easier to implement, but I don't think we should remove it from release blocker.
If we don't succeed in delivering modularity this time around, there's no story for this release. It's just a bunch of updated software.
Since modularity is now an add on, I'm inclined to think that it should not be a release blocker. Thoughts? It's a Council Objective. I think the add-on repo makes it easier to implement, but I don't think we should remove it from release blocker.
When you say release blocker, what does it mean? I can't find anything related to modular written on https://fedoraproject.org/wiki/Releases/28/ReleaseBlocking
Meh, modularity is just one of the many things happening: https://fedoraproject.org/wiki/Category:ChangeAcceptedF28
Pages in category "ChangeAcceptedF28" The following 51 pages are in this category
I wouldn't discount "a bunch of updated software" either. That's what a distribution is: a "bunch" of software, "updated" and packaged and secured and documented and tested to work together.
On 03/13/2018 10:05 AM, Matthew Miller wrote:
I wouldn't say we didn't have a story for every prior Fedora release, many of which could also be described as a bunch of updated software. I don't think that's a bad thing, and I think that is still a story. That updated software carries all kinds of new features for our users.
To jwb's point - fair enough. Just to clarify, council objectives are effectively release blockers?
In my personal opinion, it would be a good thing (for our users and also for the modular feature itself) to hold modularity until Fedora 29 so that it has had more time to bake. Most Fedora changes at its level of readiness get told "you have to wait for the next release" because we don't want to hold back all the changes that are ready. More baking/testing time will result in a more successful release, which should result in better user/critic reception and press. That's just my opinion though - if FESCo doesn't get to decide whether this is release blocking, just consider that my personal feedback to the council :)
If this is a release blocker, we really need to get that documented on the wiki and note what the criteria for success are.
Also, please don't take my comments as negativity about modularity - I personally have a change that got bumped from F27 and F28 because it wasn't ready. It happens. Of course, my change wasn't a council objective, I'm just trying to say that bumping changes isn't a bad thing.
@pnemade @bowlofeggs FESCo has the power to declare that more or less anything it likes is "blocking the release", per this policy note - it's meant to be documented in the release criteria too, but was lost in the 'NoMoreAlphas' transition (I forgot to move it from the Alpha criteria to the Beta criteria), I'll fix that.
It's generally agreed (I think) that FESCo considers the Modularity Change as blocking Fedora 28, on the basis that it's the single biggest thing we're trying to get done in Fedora 28, and of major importance to our large downstream consumer. We could throw the bureaucracy in the bug to make that clear, if FESCo wants to formally vote on it.
@mattdm I'd say that a big problem was "too much stuff happening at once". During the recent long span of time where we had a lot of compose issues, at least all of the following happened, and I'm sure I'm forgetting some:
Many of these issues fall under the general heading of 'eh, stuff happens, what are you gonna do'...but the problem is when a lot of these things are happening simultaneously or in close sequence, often with small things (like the brotli soname bump) overlapping with large things (like the mass rebuild and Modularity landing).
It may be hard to achieve, but one thing that would certainly help IMHO is if the scheduling were arranged to make it less likely that significant changes would overlap in this way. e.g. we could try to make it so that we don't try to land multiple major Changes in close proximity to each other or the mass rebuild; we could even consider implementing some sort of freeze policy to this effect.
As is the standard refrain lately, it would also help a lot if the compose process were much less cumbersome, faster, and more reproducible; it would be much easier to iterate through problems and test for at least some major changes whether they break composes before actually landing them and running a 'real' compose with them.
@adamwill Thank you for the link.
I think bug should be there to make it clear that something is being considered as blocker for Fedora 28 release. I am yet to see such bug reported and listed here.
@pnemade @bowlofeggs FESCo has the power to declare that more or less anything it likes is "blocking the release", per this policy note - it's meant to be documented in the release criteria too, but was lost in the 'NoMoreAlphas' transition (I forgot to move it from the Alpha criteria to the Beta criteria), I'll fix that. @adamwill Thank you for the link. It's generally agreed (I think) that FESCo considers the Modularity Change as blocking Fedora 28, on the basis that it's the single biggest thing we're trying to get done in Fedora 28, and of major importance to our large downstream consumer. We could throw the bureaucracy in the bug to make that clear, if FESCo wants to formally vote on it. I think bug should be there to make it clear that something is being considered as blocker for Fedora 28 release. I am yet to see such bug reported and listed here.
I've proposed it. The tracker bug should show up no the blocker bug app with the next sync.
@jwboyer the correct procedure would be for FESCo to vote on whether the bug should be a blocker, and if approved, it should just get AcceptedBlocker status applied with a comment linking to the FESCo vote and the Automatic Blockers wiki text (someone from FESCo could do that, or just ask me to do it, whatever).
AcceptedBlocker
It doesn't make sense to nominate it via the normal process, as that just flags it for a vote at the blocker review meeting, and that's not right, unless you want us to get together and vote on whether or not we think FESCo actually voted for it to be a blocker. That seems unnecessarily bureaucratic even to me. :P
@jwboyer the correct procedure would be for FESCo to vote on whether the bug should be a blocker, and if approved, it should just get AcceptedBlocker status applied with a comment linking to the FESCo vote and the Automatic Blockers wiki text (someone from FESCo could do that, or just ask me to do it, whatever). It doesn't make sense to nominate it via the normal process, as that just flags it for a vote at the blocker review meeting, and that's not right, unless you want us to get together and vote on whether or not we think FESCo actually voted for it to be a blocker. That seems unnecessarily bureaucratic even to me. :P
A FESCo member wanted it on the list. I added it to the list. I think all of this is unnecessarily bureaucratic because we're talking about it in this ticket anyway.
In today's FESCo meeting, we agreed to acknowledge the risk and close this ticket (+8, 0, -0).
Metadata Update from @jsmith: - Issue untagged with: meeting - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.