On Thu, 2011-07-07 at 17:11 -0700, Adam Williamson wrote:
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.
Much agreed, good call.
Along those lines, I was trying to come up with a way to remove the
'release blocking desktop' logic. However, that started to bleed too
much into SPIN/SIG specific criteria, and I'm not focused on tackling
that at this time.
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.
Thanks, so that's 3 votes for #3.
Unless there are any other concerns/ideas, I'll start playing around
with some templates to get a mock-up/POC out for review.
Thanks,
James