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