<br><br><div class="gmail_quote">On Wed, Apr 2, 2008 at 7:41 AM, Rahul Sundaram <<a href="mailto:sundaram@fedoraproject.org">sundaram@fedoraproject.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* 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.<br>
</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* 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.<br>
</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* Rel-eng is tasked with creating the final spin which I thought they weren't interested in.</blockquote><div><br>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.<br>
<br>The two tiered system is meant to address this issues of overwhelming RelEng.<br>If we do it correctly, the Kickstart Pool and links to external hosting on <a href="http://spins.fp.org">spins.fp.org</a> could provide enough infrastructure to satisfy a lot of spin concept needs, without ever having<br>
to burden RelEng with anything and without having submit spins to a more tightly controlled 'release' process.  <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

* 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</blockquote>
<div><br>How QA gets the testing done is QA's perview. But the tasking is most certaintly correctly scoped.  <br><br>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.<br>
<br>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.<br>
<br>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.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* Why is there a need to re-propose every spin each release? </blockquote><div><br>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.<br>
<br>But to answer you question... Why do things need to be re-proposed?<br>Fairness when doling out finite hosting resources.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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? </blockquote>
<div><br>Then we need to state...emphatically that the ARE permanent. You totally missed the point. <br>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. <br>
<br>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.<br>
 <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If spins neeed to be marked as permanent ones, shouldn't that be a decision of the spin SIG instead of rel-eng?<br>
<font color="#888888">
</font></blockquote></div><br>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.   <br>
<br><br>-jef