On Tue, 2019-09-17 at 10:38 -0400, Ben Cotton wrote: > 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?
Yes, I was thinking about that. However, that is only a proposal and maybe there is a better solution. > > 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 original idea was to run compose build for the new private tag and then make the branching with the new compose if it succeeded. > > 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. Perhaps by > making consistent compose failures more visible to the community? The main point is to have compose on the branching date or at least make the situation better than we have now. There are now other interesting proposals in the thread how to handle this. > > > 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. Thanks for the suggestion. Jirka > > > -- > 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