Developing secondary architecture release criteria

James Laska jlaska at
Fri Jul 8 15:33:51 UTC 2011

On Fri, 2011-07-08 at 08:09 -0700, Adam Williamson wrote:
> On Fri, 2011-07-08 at 11:03 -0400, James Laska wrote:
> > > If doable we should try to come up with a solution aimed at/fits 
> > > multiple release cycles
> > 
> > How do you mean ... something that works for Fedora 13, 14, 15, 16
> > etc... ?  We have that now, I just didn't include any details about how
> > the pages are updated when a new release comes along.  Adam and I have
> > talked about an SOP to cover this, but we don't have any thing final
> > yet.  
> I think by 'multiple release cycles' he meant the case where we release
> the DVD and two live images in June, the other live images in July and
> the PPC images in August, or whatever.

I see, thanks!  For scenarios like that, I'm partial to having a unique
entry point for each of those distinct "release" dates.

For example, the release criteria for the main release (DVD + GNOME/KDE
live images) is anchored at

For secondary arches, they definitely don't have to follow the main
release schedule, they'd also get their own criteria entry point.
Perhaps something like ...
%{arch}_Release_Criteria (e.g. and  These
could all be linked from the main page, their respective arch pages and
will be included in Category:Release_Criteria.  The content of the pages
would call the same templates described in scenario#3 or highlight
criteria exceptions described in scenario#2.

For SPINs whose release date isn't *tightly* coupled with the main
release date, they'd each have their own entry point (which would likely
follow the same approach used by arches).  Perhaps something like ...{spin}_Release_Criteria?


-------------- 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 : 

More information about the test mailing list