On Thu, Mar 6, 2008 at 9:45 AM, Rahul Sundaram <sundaram@xxxxxxxxxxxxxxxxx> wrote: > Jeff Spaleta wrote: > > This draft covers how new spins will be developed and released. It > > does not yet cover the issue of updated spins which incorporate > > updated packages. > > How/when are you planning on handling that? I'm really not keen on handing down a detailed theoretical process from the Board concerning spin updates, assuming we know what the problems will be. I'm pretty sure there will be problems and I'm pretty sure that if we engineer a detailed process now it will solve the wrong ones. The original spin process proposal allows for updates to be proposed as frequently as one month. I haven't heard any feedback from releng as to whether or not this is going to be a theoretical problem. But until we have an update on the table to argue about I don't see the point in trying to be more specific. I pretty much assume the first spin update will cause problems and frustrations and we'll burn that bridge when we come to it. > Your proposal doesn't seem > to address the question of whether hosting for all accepted spins will > be provided by the Fedora Project. Sorry, it was implied that any spin that releng selects as part of "Release Selection" during each release period is going to have equal access to central hosting. So infrastructure tells us how much room we have for spins early in the release runup process. The becomes a hard limit on the number of spin images that can be hosted as part of the next Fedora release (including potential updates...which we can leave some estimated room for even if we don't how we are gonna do the updates yet). Releng makes release selection decisions such that the hard space limit is not violated, but is under no obligation to use all available space available. (And if I can get more people than jwb to agree to it... then the Board has the option to champion one spin per release period beyond those selected by releng. Though that's not in the draft because its an extra complication that can be discussed once we have consensus on what release selection process will look like. It doesn't fundamentally change how this should work, but it keeps future Boards invested in the release process.) -jef _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
