On 09/03/10 19:06, Doug Ledford wrote: > On 03/09/2010 11:45 AM, Kevin Kofler wrote: > >> Jesse Keating wrote: >> >>> 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. >>> >> The assumption is that automated QA catches all possible breakage, which is >> not true. In fact *no* QA will catch all the Rawhide breakage as some is >> caused by the mere fact of things being different, which is intentional and >> part of what Rawhide is about (e.g. the libata change in the kernel, the >> change from KDE 3 to 4 etc.). Releases are needed to handle this kind of >> changes in a smooth way. But automated QA will also miss many actual bugs. >> > Things like the libata kernel change and KDE 3 to 4 migration are > intentional events and all that's needed to make the transition smooth > is to coordinate the release of a seamless upgrade package set. You > make it sound like these things are impossible when nothing could be > further from the truth. And it's expected that a responsible maintainer > is aware of these sorts of intentional update events and all that needs > to be done is for them to conscientiously build their packages into the > rawhide-candidate dist repo and coordinate a release of a complete set > of packages. Automated QA need not catch this type of event. > > And automated QA *will* catch many more bugs than it misses (speaking > from the mouth of experience knowing all the automated QA checks my rhel > packages must pass prior to each update), and there was never an > assumption that it would catch *all* issues. In fact the suggestion > that automated QA would need to catch *all* issues before the proposal > meets your approval makes it very apparent how disingenuous your stance > on this proposal is. > > FACT: the semi-rolling update model you so love today is not foolproof > and does not keep users from experiencing periodic, occasional breakage > (see KDE update thread). > FACT: you are strongly in support of the current semi-rolling model that > you practice today (see multiple threads). > FACT: you have purported that even with things occasionally breaking as > they did on the recent KDE update, that these things are impossible to > prevent 100% and that the system is working "as designed" (see KDE thread). > > So, for you to say this automated QA wouldn't catch *all* issues and > therefore this proposal is unworkable, and then on the other hand say > that major updates in RELEASED products that cause breakage are OK and > working "as designed" puts your hypocrisy very much in the spotlight. > > A consumable rawhide need only meet the level that our released products > do today (a level that you personally have helped to drag down BTW) and > at that point you have *NO* valid grounds to object to it. And if we > made rawhide meet that level of consumability, we should at the same > time be *raising* the bar for our released products. Your argument > appears to be that since we can't make rawhide meet what should possibly > be the raised bar of the released products then the idea won't work so > lets lower the bar across the board and give up. > > I'm sorry Kevin, but you and I will simply have to agree to disagree. I > will *not* capitulate to your stance on this issue. > > god you don't half talk a lot of nonsense! if you want another ubuntu go work for canonical and be done with it, fedora is great the way it is, and if you asked your users instead of assuming you know what they want you will find this out! -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
