On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Fri, 28 Jun 2013 22:13:09 +0200 > drago01 <drago01@xxxxxxxxx> wrote: > >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett >> <mjg59@xxxxxxxxxxxxx> wrote: >> > and we have no history of producing updated >> > install images. >> >> Is there *any* reason why we can't? This sounds like a reasonable >> thing to do. Just because we have not done it in the past is not a >> reason not to. > > Sure we could. We would need to: > > * Have some way to freeze things so we could stablize for the release. We should use the GA package set + the fixed build not get all updates in. It is to fix one bug not to create updated images. > * Anaconda team willing to work on updated release + next release at > the same time. The anaconda team will have to fix the bug anyway. Unless the bug requires lots of changes should be easy to backport (cherry-pick) assuming an anaconda bug is the reason why we need a release. Otherwise they don't have to do anything. > * releng folks avilable to compose stuff. > * QA folks available to run through all the release tests. Both sound doable. > * Mirrors willing to have another pile of release bits > * Marketing/press folks willing to put together stuff for the release > * Docs willing to update any release notes, etc. > * Any additional tooling needed if we call this 19.1 or something. Do we have to bump the release number? We can just update the images and let mirrors resync. > So, all this is doable, it's just a lot of resources to try and move > around, Sure it needs work but do we should care about quality of what we ship to users. If we fucked up we should try to fix it. Not just say "sorry that happened see you 6-8 months". >so personally I would only be willing to go down this road if > it was something really really really severe, That's the whole point. We should do it only if we have to. But not rule it out "because we have never done that". > and it would need buy in from stakeholders. Given that we don't point guns at people in a (mostly) volunteer driven project ... this is a given. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
