On Thu, Mar 04, 2010 at 03:59:16PM -0500, Doug Ledford wrote: > But let's be clear. That's a *policy* decision. One of the things that > got very confusing in the previous thread(s) was the intermixing of > policy decisions and technical issues. For instance, Kevin's response > So, I'm going to reiterate my policy suggestion: > > Make Fedora releases (all of them) stable in nature, not semi-rolling. > Make rawhide consumable as a semi-rolling release itself. Imho this semi-rolling is too blurry, because only the technical implementation give a grasp of what is rolling. I thought I was pro semi-rolling, but the technical proposal did not seem to fit my expectation. Here is what I would like to have as semi-rolling. What I would like to have semi rolling is as many updates that fix known bugs, even if only upstream knows them, as long as they fit these criteria: http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html And they must pass all AutoQA tests, which is not a big issue currently, but will be if AutoQA becomes what I would like it to be. All other updates should only be mandatory like every six to twelve months. Also I would like to have packages that are required to fix broken updates be taken a little bit more care of. Afaik this is what is happening with the critical path nowadays. These are my desires as mostly a user. As a packager I would like to also have some staging instance (like updates-testing), where I can stage updates that are supposed to match the criteria, but can be easily used to verify this. So I can tell users to verify that a bug is fixed, if there is no easy way to reproduce it myself, e.g. if it requires a complex setup. Since there also needs to be a repo where things can be arbitrarily broken to develop fixes, to satisfy this semi rolling approach and the stable one is to create two more repos per stable release, so we would have these: fedora - initial release updates-testing - testing updates targeted at updates updates - semi rolling wrt. to above policy outline updates-stable-staging - used to test updates for updates-stable updates-stable - only gets updates wrt. to a stable policy To lower the demand of resources, the updates/updates-testing could not be provided for the full lifetime of the release, but e.g. only for around nine months. A Milestone could be the Alpha release of the Rawhide branch of N+2, e.g. F13 updates will be supported until F15 Alpha is created, so everyone has a about a three month update window to get from FN-updates to F(N+1)-updates or F(N+1)-updates-stable. Regards Till
Attachment:
pgpK0j3yYSMtu.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
