<br><br><div class="gmail_quote">On Mon, Mar 31, 2008 at 11:37 AM, Jeroen van Meeuwen <<a href="mailto:kanarip@kanarip.com">kanarip@kanarip.com</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;">
Well, should Unity remain to be able to release Re-Spins the way they do<br>
then we'll maybe need an exemption to a couple of rules set forth in the<br>
proposal;<br>
<br>
On the Release Selection process:<br>
<br>
Spin concepts:<br>
<br>
- "can be proposed to Release Engineering for inclusion in the next<br>
Fedora release"<br>
<br>
Unity Re-Spins tend to not align with Fedora releases.<br>
</blockquote><div><br>Anything that is meant to be given official hosting space needs to run through a proposal process that is synced with the release schedule. Even if the purpose of the spin being proposed is such that it will not have images at release time, but will only have update images.   Everything that will consume project hosting resources needs to be on the table at release time with space consumption estimates. Part of the purpose of the spin release process is to make sure we adequately match our space constraints for spins to the  commitment we make for  spins over the duration of each release. <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;">The type of configuration used by the tools currently used by Release<br>
Engineering do not accept the kind of configuration a Re-Spin might<br>
need. Nor, judging from the comments on a proposal a long time ago, does<br>
upstream for those tools accept the type of configuration it might take<br>
to compose a Re-Spin with, given that -supposedly- it would not be<br>
reproducible.<br>
</blockquote><div><br><br>In the scope of the proposal, for community images that can be hosted
elsewhere, the community managed Kickstart Pool has no explicit requirements on syncing with the Fedora release process as controlled by RelEng.   The Spin SIG is deliberately stood up as a community peer group for community spin concepts, even for items that will not pass RelEng technical review.  Once there is a credible community Spin SIG and they create an initial best practices guidance.. we can start have a serious discussion about how that group can work together to produce images.  <br>
<br>Once we are able to provide shell access to a Fedora Infrastructure controlled compose host for composing signed images, the Spin SIG as a group will need to decide how they want to make use of that infrastructure to compose images with appropriate signatures.   The resulting spins will have to be hosted elsewhere in the community, but will be linkable from <a href="http://spins.fp.org">spins.fp.org</a> webspace controlled by the Spin SIG.  And yes, people are working towards making this sort of compose host access available, but its not going to happen tomorrow. <br>

<br></div></div>-jef<br>