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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
