On Tue, Oct 22, 2019 at 02:09:04PM +0200, jkonecny@xxxxxxxxxx wrote: > > I guess it will be easier to just think about the branching date when > Flock schedule is creating. However, I'm not familiar with the > scheduling so I'm probably not the right person who should answer this. Perhaps Ben Cotton could chime in here. I think now we have moved to planning the schedules years in advance, it's the flock schedule that moves around a lot based on when facilitys are available and other things. I guess we just need to take the branching date in account if it's looking like flock will be near it? > > Igor said: > > > > "I'm strongly against this as a rawhide user. We should not block > > rawhide by anything, we do snapshot of it at some point and stabilize > > it > > instead." > > > > So, any thoughts on those? I think we could perhaps drop the 'stop > > rawhide composes until we get a branched' from the proposal anyhow, > > as > > hopefully before too long we will have rawhide calling itself > > 'rawhide' > > instead of the number and this should avoid a lot of the confusion > > that > > happend this cycle with branching not being composed yet and rawhide > > composing correctly. > > If the new compose stabilization will be only a few days (which is what > we want to achieve here) then it shouldn't be a problem for Rawhide. > On the other side it could be fine without the freeze but I would like > to avoid problems when branching Fedora is pointing to a Rawhide which > is more and more diverged from what will be in the new Fedora... Yeah, although this might go away as a problem because we hope to make rawhide call itself 'rawhide' instead of the number. This means people who are on 'rawhide' will stay on it by default, and will need to distro-sync to the branched version when it appears. In the f31 cycle mirrormanager had both f31 and f32 pointing to rawhide, for the next branching mirrormanager shouldn't do that. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
