Developing secondary architecture release criteria

[Adam Williamson]

On Thu, 2011-07-07 at 16:24 -0400, James Laska wrote:

>      4. Inline exceptions - No new pages created, simply modify the
>         existing criteria pages to indicate which arches criteria apply
>         for (example at [4])
>               * PROS - No new wiki pages to create, just adding content
>                 to the existing criteria pages.  *Much* less maintenance
>                 in terms of total number of wiki pages.
>               * CONS - I like that the current criteria pages are fairly
>                 small in size.  I'd worry that adding criteria for all
>                 arches in to a single page would get too cluttered.
>                 Additionally, it's more than just the criteria lists
>                 that are impacted by the architecture (e.g. the
>                 contingency plan).  So some additional restructuring may
>                 be needed.

I'd like to add a CON to this. Currently the release criteria pages are
nice and simple: they document the conditions that need to be met for a
main Fedora release to be made. It's almost inherent in this definition
that they deal only with primary architectures: the very definition of
secondary architectures, more or less, is 'architectures that we don't
need to be in shape for release time'. If we merge any kind of
substantial consideration of things that aren't actually critical to the
primary Fedora project release into the 'release criteria' pages, we
risk diluting their clarity and purpose quite substantially. This is a
major reason the NTH Principles stuff is not on the release criteria
pages.

I think that in so far as secondary arches actually need divergent
criteria from primary arches, this should be handled in separate pages.

>      5. Something else, something simple?
> 
> At this point, I'm leaning towards seeing what solution#3 looks like.
> If that turns out to be horrible, perhaps choosing between #2 and #4.
> Of course the reason I'm sending this email is to find better ideas or
> discover any pros/cons not highlighted above.  Comments encouraged!

I'd agree with this plan, even more strongly if anything due to the
reservations I have about #4.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net