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(a)redhat.com 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