On Tue, Oct 22, 2019 at 02:09:04PM +0200, jkonecny(a)redhat.com 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