On Sun, Apr 8, 2012 at 2:57 AM, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
> let me suggest a new proposal for the primary architecture controversy:
> Let's have exactly one architecture handled as primary in Koji, picked with
> the ONLY aim of making builds as fast as possible.
Interesting idea, having Koji wait only until one of the architectures
were built might be useful in any case.
<snip>
> This proposal would only affect the build system. All the other
> differentiations between primary and secondary architectures are outside of
> its scope.
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.)
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?
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
