Developing secondary architecture release criteria

James Laska 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 [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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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 mailing list