Hi Kevin, Thanks for the explanation. See my comments below. On Tue, 2019-09-17 at 09:28 -0700, Kevin Fenzi wrote: > On 9/17/19 8:04 AM, Miro Hrončok wrote: > > On 17. 09. 19 17:00, jkonecny@xxxxxxxxxx wrote: > > > If that is not doable what about taking last Rawhide compose and > > > mark > > > that as first compose of newly branched Fedora? The only thing > > > I'm > > > asking for is to have a base ground which is not available right > > > now. > > > > That is actually a nice proposal. I wonder whether it is > > technically > > possible. CCing (hopefully) relevant people. > > It is not. > > Branching is not just "oh, make a new compose". There's a ton of > steps/work that happens then, including: > > * Making a new branch on all active rpms > * Switching to a new signing key in rawhide. > * New pungi-fedora config, new comps, new kickstarts. > * Setting up new koji tags, etc. > > I'm sorry for the delay in a f31 compose this time. ;( I don't think it's your fault or anyone else. I think it's a fault of the system here and that is what I want to fix. > > Here's my suggestions: > > * Make sure branching isn't right after flock. Mohan was traveling > and > we were both jetlagged so I think it was harder to watch things. Definitely good point! > > * We should leverage rawhide gating in the next branched: Set it up > for > gating just like rawhide (this time we didn't) and then actually > disable > allowing new builds in until we have a compose. This would hsave > saved > us many days of people landing broken stuff we had to sort out. We > could > at least get a compose to have to start with. The next compose might > get > a pile, but at least we don't have to fight a moving target. > > * somehow figure out the pungi-gather segfaulting issue and fix it. > This > doomed several composes. > > * Now that we have composes somewhat faster, we can run 3-4 a day at > least, so that should speed up fixing things. > > * Stop rawhide composes until we have a branched compose. This may > not > be needed with the change to make rawhide use 'rawhide' and not the > number, but we should consider it if we don't have a compose to avoid > confusion. Where should I signed this? :) But now for real, from my understanding you are basically proposing improved version of what Miro mentioned somewhere here in the thread. That means make freeze after branching. I definitely agree on that. Aside of that you are suggesting Rawhide should freeze too before the branched Fedora has a compose. Not sure if that would really help because if the Rawhide will *unfreeze* the same date as when the branched Fedora have first compose then we don't have a time to react. In my F31 case most importantly copr will be in similar situation that they will use Rawhide *new* compose (if they won't be really fast) instead of the old one for a new Fedora chroot. And I don't think we want to add some lag between the successful Fedora compose and the Rawhide one. Other than this one point I agree with what you just wrote. Jirka _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
