Target audience

[Jesse Keating]

On Mon, 2009-10-26 at 20:26 -0500, Mike McGrath wrote:
> I think this would be a good FUDCon topic actually.  We've gotten pretty
> ok at ballparking stuff like this.  I think the logic to find this number
> would look something like this:
> 
> 1) The more experimental rawhide release would behave almost exactly as it
> does now.  Probably some additional builds because people will be quicker
> to try stuff out.  Since we don't have this number I might propose an
> additional 10%, I'll look through logs though to see if I can't get a
> better feel for this.
> 
> 2) The less experimental rawhide (next-release) would likely have fewer
> builds then the experimental rawhide (and probably fewer then the current
> rawhide) but probably more then what is in our current stable release.
> 
> Question: Will the workflow go from experimental -> next release or will
> builds be separate?

Builds will be separate.  At the time of branching, all the builds from
experimental will be bundled into the next release tag, but from that
point on we'll have branched SCM, so if you want to build for
next-release, you have to build from a branch, which will go to a
different target and buildroot and etc.. than builds from devel/.

> 
> > - How many extra resources in terms of storage, man-hours and ...
> >
> 
> If we aren't signing next release or rawhide (or are signing them with the
> same key at some point in the future) then we can hardlink between rawhide
> and next release to save some storage both on /mnt/koji and the mirrors.

That would be the plan.  Ideally we're signing everything with a Fedora
Build Key, and that would be the only key in use for the rpms.  All
hardlinking all the time.  If that doesn't happen, then we'll be able to
hardlink from experimental into next release, until it comes time to
sign everything in next release at which point hardlinks break.
Hopefully we won't go that route.


-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20091026/427992c1/attachment.sig>