On 03/02/2010 08:55 PM, Matthew Woehlke wrote: > Jesse Keating wrote: >> On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote: >>> You and everyone else, please stop proposing Rawhide as the solution for me >>> and people who want the same "update everything that doesn't break things" >>> policy, it does NOT fit our usecase at all! >> >> If you don't like rawhide for that use case, find another operating >> system. I'm tired of our stable releases getting tonnes of updates. >> I'm tired of what F11 shipped like being completely different today. >> I'm tired of waiting for many many hours while we try to compose out the >> 3444 individual updates in F11 stable. (that's right, 3444 srpms worth >> of updates. F11 only had 7446 srpms to begin with!!). This is not the >> style of distribution I wish to produce or consume. If this is the >> style of distribution you wish to produce or consume, then I encourage >> you to go find another distribution or start your own. > > Okay, I have to ask: why are you right and Kevin is wrong? What makes > your vision of Fedora more worthy than his? (Especially when his is the > apparent incumbent?) And especially given that he cited as many things as he did in Fedora docs about doing things the way he does. Unfortunately, there are people on both sides of this fence and making Fedora a one size fits all distribution will necessarily piss off one group or the other. Which is why I said in a previous email that I would prefer the bugfixes/backports split that Mandriva has because that allows you to satisfy both sides of the fence. I saw this train a comin'. We might could compromise along the lines of what I wrote in that email in terms of splitting which packages are update happy and which are considered stable among some line that would satisfy the majority of people, but I really think you need two update streams to fully satisfy people. That or we would have to go with another alternative entirely. People have (well, to be fair mainly James, but he's right I think) pointed Kevin at rawhide time and time again. And Kevin has pointed out (also rightly) that rawhide isn't really consumable. So, we fix that. We make rawhide consumable, you make rawhide the thing that people track if they want continuous rolling updates, and you make the actual releases more stable. How would you make rawhide consumable you ask? Ah, well, I'll make the following, totally out of my ass and probably not feasible proposal: Along the lines of "no frozen rawhide", a new rawhide-testing repo is created. By default, all builds from devel go into rawhide (gothca didn't I, you thought I was going to send them to rawhide-testing but I'm not ;-). However, we have a set of automated tools that check for things like dependency breakage, API changes, etc. (maybe using rpmdiff or the like). If those tests trip positive, then the package is moved from rawhide to rawhide-testing. Alternatively, a developer can build directly into rawhide-testing for known disruptive changes like soname bumps and the like. That way rawhide-testing becomes a staging area. We both encourage maintainers pushing changes they know to be disruptive to build there, plus we have tools that will catch some classes of disruption and move them there. Once a package gets caught up in rawhide-testing, the way to get back out and into rawhide is to fix the disruptive change. If the change was an sobump, then in addition to the package itself, we would need rebuilds of all the dependent packages in rawhide-testing so that they can be pushed en masse. The solution would be dependent on the type of breakage the package was found to cause, but the general idea is to stage the changes here until they are ready to hit rawhide all at once and in a way that doesn't break the consumability of rawhide. I would maintain nightly pushes of rawhide packages, but might make the rawhide-testing -> rawhide thing only happen on an as-needed basis (and hopefully that won't be too often, maybe no more than once a week on the high side I would guess, but that number's totally out of my ass). Then there are the releases. You wean back the updates in stable releases to things that are actually necessary. I admit I have filed updates myself that weren't really necessary except they helped me keep everything straight in my head. So, what does actually necessary mean? I guess that's up to discussion, but I would throw in my points: 1) Bug fixes and security updates (no one would argue these shouldn't be sent out) 2) Enhancements? Dunno...are people requesting the enhancement, or are you just throwing it in to keep F-11/F-12/F-13 the same so you don't have to think about what's different between them like I sometimes do? I think there's a bit of wiggle room here. Some things I could see saying yes to, others no. 3) Wholesale upstream updates? Dunno, see #2. > Some of us like Fedora just fine the way it is, and don't want to see it > change to match your vision. Fair enough, and I don't really like the constant stream of updates. There are obviously people on both side of this fence, and I would hope that we might be able to find a solution that doesn't require one group or the other to walk away from Fedora. Which is why I've outlined what I did above. The only two ways I can see to satisfy both groups are: 1) Make a rolling rawhide consumable and move anyone that wants constant rolling updates there while making point releases stable and 2) Have two independent update streams for each release similar to the bugfix/backport streams Mandriva has An option that doesn't satisfy both groups is to put things to a vote and whoever wins buys the loser a box of chocolates and a card that reads "Too bad, enjoy the rest of your week". If things aren't so bad as to require immediate action though, then the head in sand, live with status quo option is the one most often taken. I'm not qualified to speak as to whether things are actually bad enough to push people to opt for a different option. Well, if either group doesn't hold at least a reasonable number of members though, it might not be worth it to do any sort of technical solution to the issue as the benefit might not cover the implementation costs. In that case, do the vote and let the little, itty bitty group, whichever that may be, cry in their beers while they eat their consolation chocolates. (Sorry, as heartless as it might be, it is still an accurate bean counter truth) -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel