Target audience

[Mike McGrath]

On Mon, 26 Oct 2009, Jeroen van Meeuwen wrote:

> On 10/26/2009 09:37 PM, Paul W. Frields wrote:
> > Finally, the Board talked about the proposal for "unfrozen
> > Rawhide,"[4] which Jesse Keating offered at a Fedora event this
> > summer.  Just like many of our contributors, we've felt the pain of
> > having an uninstallable Rawhide, which negatively affects everyone's
> > ability to more efficiently deliver new code and features.  In
> > essence, Rawhide has been too often "eating babies" indiscriminately,
> > and we need to improve its contribution to our develoment ecosystem.
> > The Board feels that Jesse's proposal not only has the potential to
> > help us achieve a more installable Rawhide, but if it's managed
> > correctly we could have a Rawhide that more of our core contributors
> > could actually use during and prior to test phases -- while not
> > undoing our ability to allow and encourage innovation and new ideas.
> >
>
> I'm thinking of this while we're talking about target audiences and their
> experiences... Where was it again I had heard an argument for improved
> consumer experience before?
>
> And so, because I've had this kind of conversation with the board before, not
> because I actually care about the answer on any of those questions;
>
> - How many extra builds do we anticipate for unfrozen rawhide vs. rolling or
> pending release?
>

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?

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

I should also mention that we've started doing more aggressive garbage
collection on /mnt/koji to save space.  Also our public mirror system is
now 4.5T in size though we've sort of made an unspoken agreement to keep
fedora-enchilada and epel to under 1T as to not overwhelm the mirrors.

I'll chew on some of those questions a bit at least for the storage side
of things.

	-Mike