On Tue, Jun 29, 2021 at 08:36:36AM -0400, Stephen Gallagher wrote: > On Mon, Jun 28, 2021 at 3:00 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote: > > > Summary: I think we can fix the ELN side-tag rebuild problems and make > > > the composes more reliable if we change the mechanism for kicking off > > > rebuilds. I'm soliciting feedback to help identify potential issues > > > with this proposed approach. > > > > I wonder if it would be better/possible to take builds in the order in > > which they were built in the side tag with wait-repos between? > > > > ie, chain build the builds from the side tag based on when they were > > tagged into it? Unless maintainers make some mistake they would do > > things in the order they need to build, no? > > > > I guess the downside is that this would be linear, and that could take a > > long time on a large sidetag, but it should work without having to tag > > in the f34 build? > > This was the original idea I was pursuing, but it has some significant > drawbacks, not least of which is that it would take a very long time > (and therefore be vulnerable to race-condition issues where other > packages are built in ELN in the meantime). > > Tagging in the F34 builds is actually desirable here, rather than a > drawback; it means that even if the ELN build fails, the compose will > maintain installability and dependency validity until the issue is > corrected. This in turn means that Content Resolver will be able to > continue functioning. Speaking of Content Resolver, this will also > solve the issue we have today where adding a new dependency on a > package can cause Content Resolver to fail due to the dependent > package not yet being in the ELN compose. With this approach, we will > still have the Rawhide version available. Would these rawhide builds go out in ELN composes? Or would you block composes until you had only eln rpms in it? 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
