On Mon, Mar 31, 2008 at 11:37 AM, Jeroen van Meeuwen <kanarip@xxxxxxxxxxx> wrote:
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.
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.
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 spins.fp.org 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.
-jefWell, should Unity remain to be able to release Re-Spins the way they do
then we'll maybe need an exemption to a couple of rules set forth in the
proposal;
On the Release Selection process:
Spin concepts:
- "can be proposed to Release Engineering for inclusion in the next
Fedora release"
Unity Re-Spins tend to not align with Fedora releases.
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.
The type of configuration used by the tools currently used by Release
Engineering do not accept the kind of configuration a Re-Spin might
need. Nor, judging from the comments on a proposal a long time ago, does
upstream for those tools accept the type of configuration it might take
to compose a Re-Spin with, given that -supposedly- it would not be
reproducible.
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.
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 spins.fp.org 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.
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
