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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
