Re: Developing secondary architecture release criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux