Spins proposals

Wed Apr 2 17:06:22 UTC 2008

On Wed, Apr 2, 2008 at 7:41 AM, Rahul Sundaram <sundaram at fedoraproject.org>
wrote:

> * IMO, it would be better to do a public proposal to fedora-devel list and
> then take it to spins SIG so we get more public feedback on new spin
> proposals.
>

You are free to discuss it anywhere you want before taking it to the spins
SIG to start the process of getting trademark approval.  If the Spin SIG
wants to require -devel-list discussion as best practices that will be their
call.  I'm not going to block on the organizing of a general framework meant
to better balance how RelEng, the Board and the community all fit together,
based on whether or not its a best practice to discuss things on
fedora-devel.

> * Release selection process doesn't say whether or not a older spin for
> the older release or the current release will be retained when there is a
> updated one available.
>

RelEng's call, which will impact space estimate considerations at release
selection time.  If RelEng want's to keep the gold release around for each
released spin, then that's how hosting space estimates will be handled.
>From discussion I expect RelEng to require the goal release to be retained,
which will drop the number of spins that can be released.

> * Rel-eng is tasked with creating the final spin which I thought they
> weren't interested in.

Rel-eng, I'm pretty sure, is interested in...releases.  This process ties
spin release selection to the actual fedora release process. Which is
completely different than what we have now, where spin concepts are a
running submission que that can't be easily planned for. So this proposal
organizes RelEng's role such that RelEng can work in selected spin composes
into the overall pre-release testing aimed at a release.

The two tiered system is meant to address this issues of overwhelming
RelEng.
If we do it correctly, the Kickstart Pool and links to external hosting on
spins.fp.org could provide enough infrastructure to satisfy a lot of spin
concept needs, without ever having
to burden RelEng with anything and without having submit spins to a more
tightly controlled 'release' process.

* Fedora QA is tasked with testing all the release spins. Nominally being
> part of that team, I don't think QA has the resources (ie) enough people
> involved considering that we have a six month release cycle and lots of bugs
> to deal with

How QA gets the testing done is QA's perview. But the tasking is most
certaintly correctly scoped.

I will be blunt.  I think we've had a significant problem with the QA
process for multiple releases now.   We must find a way to organize
volunteer labor better with regard to QA..generally.

If QA wants to officially get on the record as saying they aren't going to
take the responsibility of testing the composed images that RelEng has
selected and working on as part of a release cycle... then by all means get
on the record....as a group put your foot down in protest...so I can come in
with my riot gear and tear gas and bust some skulls.

Or QA as a group try to get involved with the formation of the Spin SIG and
make sure they are well prepared to do a significant amount of the QA as
part of Kickstart Pool management.

I think you are missing part of the point as to why the Spin SIG and the
Kickstart Pool is being setup to begin with.  The Spin SIG may very well
find that its in their mutual best interest in getting involved more
directly in the QA process..even before a spin has been selected for
release.  And it very well maybe in QA's best interest to find a way to
guide the Spin SIGs involvement in post-release testing as well.  But that's
a conversation for the Spin SIG and QA to have at some point between now and
the start of the F10 release cycle.

> * Why is there a need to re-propose every spin each release?

First of all.. that was from the supplement url for ideas that need further
discussion. It should not be construed as being part of the basic framework
that must happen to make room for the Spin SIG.  I wish you had taking the
time to post a separate thread concerning the supplemental ideas, as to
avoid any confusing this idea is part of the basic framework. It isn't.

But to answer you question... Why do things need to be re-proposed?
Fairness when doling out finite hosting resources.

> Spins rotation talks about throwing away established spins in favor of
>  new spins unless rel-eng decides it is a permanent spin. If spins are long
> live, doesnt that by itself mean it more of a permanent spin with enough
> users around it and we shouldn't throw it away?

Then we need to state...emphatically that the ARE permanent. You totally
missed the point.
Its about fairness with regard to resource consumption.  I do not want a
situation where we consume all available hosting space with permanent
spins.. release after release...making no room for additional concepts that
are technically viable and deserve a chance at a wider audience by being
part of a release, part of the release notes, and part of general release
propaganda.

So I setup a situation where we have to be explicit.  If a spin should be
permanent we state that it is..and we make sure that we have a hosting
commitment for an additional rotating spin before we give a spin permanent
status.     If we do things correctly.. we will never really need to throw
away a long lived spin, because the 'right' people will have a policy backed
incentive to make sure we have the hosting in place to keep the permanent
spins around.  And at the same time, we never give the false impression that
a niche spin is going to be available every single release.  Permanence
will be a higher bar than release selection.

If spins neeed to be marked as permanent ones, shouldn't that be a decision
> of the spin SIG instead of rel-eng?
>

Not really.. since release selection is completely scoped with Rel-Eng. This
is a modification to what Rel-eng is tasked to do...the making of final
release selections for each release.  Surely the Spin SIG will have input,
but the decision is Rel-Eng's because the release selection decision process
is controlled by Rel-Eng.

-jef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20080402/c2dfbb2c/attachment.htm>