On Tue, 2019-09-17 at 16:31 +0200, Miro Hrončok wrote: > On 17. 09. 19 15:58, jkonecny@xxxxxxxxxx wrote: > > I want to ask for an improvement here. Ideal solution for me would > > be > > to add rule that there have to be compose to do the branching and > > if > > the compose fails then the branching won't happen. > > We need to branch before we do the branched compose. Even if we check > that > rawhide composes prior to branching, there is no guarantee that > branched would > compose right after it. Are we able to make the compose on fedora-31-candidate in temporal tag and then make the branching based on result? 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. > > Ultimately, what happens if rawhide doesn't compose? You delay > branching until > it does? How does that help with "beta freeze happens too soon after > the > branched compose" problem? I guess that the freeze date could move based on the branching date? The point is to avoid situation that you have to flick something without knowing what's inside and most importantly with a backup which is not available without the compose. Basically not having to make temporary solutions to pretend that you are testing branched Fedora everywhere. For example one of the problems what happened was about our daily COPR builds. There were no chroot for Fedora 31. In the time when Fedora 31 chroot was added the last chroot from Rawhide was used as new base Fedora 31 chroot -- that behavior seems correct to me because Fedora is based Rawhide. However, Rawhide chroot had already much newer version than it's on Fedora 31 (thanks to the delay) and with python 3.8. That meant that we had to remove all our daily builds manually and run the build again just because there were no compose on the branching date. I don't see a reason why that should happen. When there were no branch for Fedora 31 than the python 3.8 changes wouldn't land (or I expect that) and even if that would happen we would work with python 3.8 everywhere correctly. The python 3.8 is just our current situation but it could be anything - new gcc, git, make any of those could broke tests or builds. Jirka > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > 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 _______________________________________________ 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
