On 07/07/2011 08:24 PM, James Laska wrote: > Greetings folks, > > I'm interested in developing a solution to allow Fedora secondary > architectures [1] (specifically ppc64 and s390x for now) to leverage our > existing release criteria [2]. This isn't really a tremendously > difficult technical challenge, more of a content organization conundrum. > The part I'm wrestling with is how to do it in a way that it compliments > the current release criteria process. I apologize in advance for this > rather long email. > If doable we should try to come up with a ( long term ) solution completly architectures independed since I would not be surprice for example if arm would jump the train in not to distant future.. > For some background, here are some key differences between primary and > secondary architectures. These are worth noting as I believe they'll > impact how the criteria are created and applied. > > 1. Different release schedule - secondary architectures don't > follow the same release schedule, so secondary architecture > blocker/NTH bugs shouldn't block the main release. This is good > since we have enough primary architecture blocker bugs > already :) If doable we should try to come up with a solution aimed at/fits multiple release cycles > 2. Different target audience - Depending on the architecture, > different outcomes may apply for certain criteria. For example, > on s390x ... there is no Desktop outside of using VNC. > Therefore, the graphical boot, firstboot, login don't apply and > many remaining desktop criteria are NTH, not blockers. I would think they have same/similar target audience as server sig hence perhaps it would be good to include them in this discussion. > 3. Community size - I don't think this is a surprise, but the > secondary architectures tend to have smaller communities of > interest. That's not to say there isn't interest, just the the > number of people involved/contributing may be substantially > smaller than the primary architectures. Any solution needs to > be sustainable by+for that community. > > Okay, recognizing the differences ... it might help to outline what I'm > hoping to accomplish. Some goals include .. > > 1. Do _something_ - better than doing nothing :) Agreed > 2. Minimal criteria duplication - I don't want anyone to have to > write/maintain the same criteria in multiple places. That just > seems like the worst-case-outcome. Agreed > 3. Low maintenance - somewhat related to the above goal, but not > entirely. Whatever solution we choose, I'm hoping it isn't a > hard-to-document wiki challenge. Agreed > 4. Minimal impact to primary release criteria + process - > personally I'm pretty happy with the current criteria > +process ... I don't think that's in need of a major overhaul at > this time. I think this is yet another indicator on we actually need to start looking at an overhaul how major depends on the solution we come up with. > To meet these goals, here are some solutions I've been thinking about so > far. Note, not all of these are good ideas, I'm just thinking outloud > in the hopes of getting creative juices flowing. If something doesn't > make sense, or is wrong ... don't hesitate to point it out. > > 1. Full duplication - Draft individual wiki pages for each arch and > each milestone (Alpha, Beta, Final). Each page would outline > custom criteria for that architecture+release pair. > * PROS - are there any? I guess this solution offers the > most customization for each secondary architecture > * CONS - ugh, painful to create, maintain and keep in sync > all that wiki content and pages. This definitely > competes with the "minimal duplication" goal. > 2. Highlight differences - Draft individual wiki pages for each > arch for each milestone (Alpha, Beta, Final). However, instead > of duplicating all applicable primary arch content, only > highlight the differences between the primary and secondary > arch. > * PROS - A little less work than the full-duplication > approach > * CONS - Still a lot of wiki maintenance. Not necessarily > in terms of wiki content, but definitely in terms of > wiki pages. Having plenty of experience trying to > figure out whether a but impacts criteria, I think this > creates additional hoops to jump through to figure out > if a bug impacts the criteria or not. > 3. Wiki Templates - Draft individual wiki pages for each arch for > each milestone (Alpha, Beta, Final). However, instead of > creating new criteria, or highlighting exceptions, simply call > the common template (with any optional template arguments). > This also involves converting the existing criteria into > official mediawiki templates (e.g. > Template:Fedora_16_Alpha_Release_Criteria). All existing > criteria pages would then call the main template, providing any > template parameters needed to display/not_display specific > criteria. A *small* sample of how this might work is available > at [3]. > * PROS - One stop shopping for each architecture when > trying to figure out if a bug impacts the criteria. I > don't need to reference the ppc64 criteria, and then the > primary criteria. It's all on the single page for each > milestone (alpha, beta, final). Note, templates are > already used in the existing criteria to avoid > duplicating the pre-amble, so this isn't too unusual. > * CONS - a fair amount of prep work creating the template > and parameterizing different sections. I'm also not yet > sure what parameters would be needed (perhaps they'll > grow over time)? > 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. > 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. Aggreed leaning the same way.. > 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 would say we should/need to start coming up with criteria based targeted @groups that would solve both arch and multiple releases. JBG Note that we are faced with solving the same problem with multiple spin release so the solution we come up needs to be both arch independed and spinn idepended -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
