Re: Add a rule to have a compose when Fedora branched

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux