Developing secondary architecture release criteria
jlaska at redhat.com
Fri Jul 8 15:07:47 UTC 2011
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 )
> > * 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110708/922026ff/attachment-0001.bin
More information about the test