Primary Architectures: Another Proposal (RFC)

Kevin Kofler kevin.kofler at chello.at
Sun Apr 8 12:34:25 UTC 2012


Miloslav Trmač wrote:
> How is this in practice different from
> a) the package maintainer looking at the build logs of the
> fastest-building architecture as soon as that architecture builds, and
> ignoring the rest?  (The maintainer can do this right now.)

* The build might be faster if we find a way to build packages faster than 
the fastest shipped architecture. (As a simple example, we might try 
building packages with -O1, and stuff often used in builds (toolchain etc.) 
with -O3, whereas the shipped packages would still use -O2 as always.)
* Chain builds would be able to proceed immediately (on the primary 
architecture).
* Updates would be able to be filed as soon as the primary build completes 
(see below).

> b) the existing primary architecture definition, where updates,
> releases and release criteria wait for all primary architectures?
> 
> Specifically, I'm unsure about the interaction of this proposal with
> bodhi (can an update be pushed to stable even if only the
> fastest-building architecture was built and got karma?), and the
> meaning of release deadlines (does the "beta change deadline" count
> against the fastest-building architecture or all of them?) - it seems
> to me that the natural answer to these questions is, in both cases,
> "all architectures must be tested and usable for the update/release to
> be published", and I can't see the difference in that case.  Perhaps
> you have a different idea of how bodhi and the release dealines would
> be treated?

The idea would be that you'd be able to file and queue the update in Bodhi 
as soon as the primary build completes, just as now, except that "primary" 
would now be the one, possibly fake, architecture. The updates could even 
get pushed right there, for the internal primary architecture only. They 
would then be synced to the actual architectures, just like secondary 
architectures are synced now. It'd be Koji's and/or Bodhi's job to 
automatically push the matching updates for the real architectures to the 
matching repositories as soon as the builds complete. The infrastructure 
needed for that is needed to properly support secondary architectures 
anyway!

        Kevin Kofler



More information about the devel mailing list