On Thu, 2019-09-19 at 14:29 -0700, Kevin Fenzi wrote: > On 9/18/19 1:41 AM, jkonecny@xxxxxxxxxx wrote: > > Hi Kevin, > > Thanks for the explanation. See my comments below. > > ...snip... > > > > * 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. > > Well, I was not saying we should go into Beta freeze immediately and > stay in it until Beta is out. I was just saying we should have a > temporary freeze right after branching until we have a completed > branched compose. Then we can open things up again until Beta freeze. As Miro already answered, it's not about beta freeze but a new freeze you just described. > > > 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. > > Well, I am not sure we need to stop rawhide until we have a branched > compose. This time it would have helped because mirrormanager pointed > all the branched repos to rawhide since there was no branched, so it > caused a lot of confusion. > > if we can land the change to make rawhide use 'rawhide' as it's > version, > it would avoid this confusion, as people wanted to switch to branched > would need to explicitly sync to it (which means it has to exist). > > > 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. > > I'm not sure what you mean here, can you expand on it or provide an > example? What COPR was doing (I think they changed it after F31) then before a new chroot in COPR appeared they copied the latest Rawhide chroot to have something working in the new chroot. So, if we build the new Rawhide the same day as F31 branch compose is ready then they don't have a time to react and sync "the old Rawhide" version. However, that above is just an example of what happened to me. I think most of people here dealing with this stuff have to somehow react that the compose is available. So or so, you are trying to solve something else by the freeze than me. I'm not sure If I can help you with the "Rawhide freeze" decision I didn't had the problem you are describing. 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
