----- Original Message ----- > From: "Ben Cotton" <bcot...@redhat.com> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Tuesday, September 17, 2019 4:38:50 PM > Subject: Re: Add a rule to have a compose when Fedora branched > > On Tue, Sep 17, 2019 at 10:00 AM <jkone...@redhat.com> wrote: > > > > I want to ask for an improvement here. Ideal solution for me would be > > to add rule that there have to be compose to do the branching and if > > the compose fails then the branching won't happen. Not sure if this is > > doable or how hard it would be to implement a similar rule, however, it > > would be an ultimate solution. Then, the compose blocker bugs had to be > > solved on Rawhide where they should be solved. > > > I want to make sure I understand what you're proposing. You're > suggesting that we shift from having the branch point be a defined, > specific date in the schedule to having it be a range of possible > options. So it would be more like the Beta and GA releases where we > target a day, but slip if we're not ready. Is this right? I understand the need for having reasonably specified set of dates so that people can plan their work around them. But simple triggering branching without any prior smoke test/dry run or CI & blindly following the dates regardless of the result does not seem like a good idea to me.
We could change the branching date to Not Earlier Than, branch on the date and only start the countdown for the outer milestones once there is a compose and possibly other pieces in place (Mock/Copr chroots, etc.) for people to actually get anything done on the branched release. > > So how recent of a rawhide compose qualifies? If there's a successful > compose in the last week, is that okay? Does it have to be the night > before the branch point? Are there other judgments that go into (like > in the go/no-go meeting) or is it entirely based on the compose? > > My initial reaction is that this in an outlier and that we shouldn't > make structural changes to the schedule in response to outliers, but I > wonder if there are other guardrails we can put in place. I'm afraid this is not an outlier as compose failures still happen very often, it was simply that we got a streak of them at the worst time possible. In other cases they might not be so visible, but still regularly cause pain to Fedora contributors and users. To improve the situation there are basically two things to consider: - what development milestones should require a successful compose before we move forward with them - what breaks the compose & how we can avoid it, possibly by doing dry runs/CI runs on things before we introduce them to the compose cauldron > Perhaps by > making consistent compose failures more visible to the community? > > > Please tell me what should I do next. Should I file a FESCO ticket to > > add this rule? > > > I expect FESCo will want to wait until the community has had an > opportunity to discuss this first. I suggest waiting a week or so > (depending on how long the conversation remains productively active) > and then filing a FESCo ticket. > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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/devel@lists.fedoraproject.org > _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
