Developing secondary architecture release criteria

[James Laska]

On Fri, 2011-07-08 at 12:49 -0500, Dennis Gilmore wrote:
> On Friday, July 08, 2011 10:10:33 AM James Laska wrote:
> > On Fri, 2011-07-08 at 16:15 +0000, Dennis Gilmore wrote:
> > > >      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.
> > > 
> > > I think that this is the way to do it. one page per secondary arch noting
> > > differences, for instance sparc is likely to be almost exactly the same,
> > > there is a desktop and server target. so differences really will be
> > > minimal.
> > 
> > This will be my first fall-back scenario if I can't get something folks
> > like with the wiki templates.  I'm not real keen on having to inspect
> > *multiple* pages to figure out whether a proposed bug is a blocker or
> > not.  But this approach definitely would be simpler in terms of wiki
> > magic.
> 
> Secondary blockers are primary NTH, but never primary blockers.  a primary 
> blocker  i guess could be a secondary nth.  but i highly doubt it.

That is the correct, and currently undocumented approach.  Note, that
developing release criteria for secondary architectures is intended to
*only* apply to that secondary architecture.  This in no way affects the
process or schedule of the primary architectures.  In fact, I'd like to
keep them separate entirely. 

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/c0176c09/attachment.bin