On Thu, 2010-03-04 at 15:59 -0500, Doug Ledford wrote: > 1) Make rawhide consumable. > A) Create rawhide-unstable. Any time a known disruptive change is > being worked on, it should be built here by the developer. In > addition, add rpmdiff checks to all builds from devel into > dist-rawhide and if any of certain rpmdiff checks trip positive, > move the package from rawhide to rawhide-unstable. Additional > checks can be added as AutoQA gets into full swing, and so we can > add more ways to catch breakage and move things to rawhide-unstable > as needed. Slight variation on this. All builds from devel/ (or master in the new git world) would go to the koji tag dist-rawhide-candidate. Builds which are tagged with dist-rawhide-candidate trigger AutoQA tests, of the nature "rawhide acceptance" (this would have to get fleshed out at some point, but it'd be something that builds upon the tests we would already do post-build). Builds that pass rawhide acceptance would get tagged into dist-rawhide, would show up in the build roots, and would be part of the nightly rawhide compose. Builds that do not remain in dist-rawhide-candidate. A maintainer can review the failed cases and make a decision, override the system or do a new build. Egregious use of system overriding would trigger FESCo attention and perhaps some sort of retraining or sanctioning. > B) Non disruptive changes go into rawhide directly, and on a regular > basis we run a compose on the rawhide tree to create install > disks/images for use. I suggest once a week we recreate the > images. I'd leave the install images creation out of this for now, that's primarily a decision for the anaconda developers to make, as to when they wish to have mirrored install images created and used for bug reporting. > C) On a regular basis, we have a flag day to move items from > rawhide-unstable to rawhide. I originally said as-needed in my > first proposal, but on more reflection I would like to suggest > we make this a regular scheduled event on a monthly basis. In > this way we have 6 regular rawhide-unstable==>rawhide checkpoints > between each release cycle, and we can make the last one or two > prior to the next fedora release do double duty as both the > normal checkpoint and the fedora alpha/beta freeze. This also has > the side benefit that people working on major changes, like say > anaconda install updates, have more points at which they can get > their code into a consumable segment of the repo and start getting > feedback. That's an interesting thought, coordinated moves from either untagged or dist-rawhide-candidate over to dist-rawhide. > D) Anyone who likes that rawhide allows them to develop directly > on their OS can simply enable the rawhide-unstable repo in their > yum configs. Like enabling updates on a regular release, it > would inherit from rawhide and also include all the distruptive > changes. This makes a system with rawhide-unstable enabled > identical to rawhide today. I think we could accomplish this with a simple koji static repo. It's far cheaper than trying to do a full multilib mashed repo every night of this content, and it gets updated far more frequently. > E) Without rawhide-unstable, you get a semi-rolling release that > allows for regular checkpoints to introduce disruptive changes, > soname bumps, etc. only on a more frequent basis than the current > fedora release cycle. It is hoped that by having this higher > frequency, disruptive changes in the semi-rolling release that is > rawhide can be handled more easily. Kind of along the lines of > easier to deal with by taking more, smaller bites instead of huge, > hard to swallow bites. I think there is room to do soname changes more frequently than the scheduled disruption days, provided that all in Fedora consumers of a soname are bumped at the same, or at least moved into -rawhide at the same time. This would require a higher level of coordination, and more specific koji buildroots. A tax on the system, to be sure. > > 2) Make Fedora releases adhere to a stable release policy. This already > covered rather well in proposals put forth by other people. Mike > McGrath's snapshot proposal and Matt Domsch's Slowing rate of change in > older releases proposal are the two I would pair with my proposal in > order to satisfy both groups. I don't see any reason to rehash them here. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
