RFC: Primary architecture promotion requirements

Josh Boyer jwboyer at gmail.com
Tue Mar 20 15:47:44 UTC 2012


On Tue, Mar 20, 2012 at 11:37 AM, Tomas Mraz <tmraz at redhat.com> wrote:
> On Tue, 2012-03-20 at 15:19 +0000, Matthew Garrett wrote:
>> This is very much a draft, but I'd like to start a discussion regarding
>> what we expect from primary architectures. Feedback not only welcome,
>> but actively desired.
>
>> In order to ensure that these expectations are met, secondary
>> architectures must meet various criteria before they can be promoted:
> ...
>> 4) All supported platforms must have kernels built from the Fedora
>> kernel SRPM and enabled by default in the spec file. Each kernel must be
>> built in a timely manner for every SRPM upload.
>
> I do not like this requirement. This seems to be specifically provided
> to block the possibility to have ARM as a primary architecture if we do
> not want to support just one or two ARM platforms. I do not really see a
> problem in limiting platforms during rawhide development and branched
> development. Additional platforms could be enabled for final builds
> before the release freezes and for update builds.

There's nothing blocking ARM from building multiple kernels in that
requirement.  They just need to all be enabled in the SRPM that gets sent
to koji for the build.  We do this for 32-bit x86 already by building both
the normal and PAE i686 variants.  The intention is to basically have a
consistent and reproducible build for all kernels built from a single SRPM.

I really don't think we want to enable additional kernels for final builds
that have not been tested at all during development of the release.  That
doesn't make sense at all and sounds like poor engineering practice.

> Another solution might be in koji where the kernels for the additional
> platforms would be built in parallel on multiple build hosts. Of course
> that would require changes in koji.

That would be acceptable of course, and it would still fit with the
requirement above just fine.

josh


More information about the devel mailing list