On Friday 10 March 2006 13:58, you wrote: > On Fri, 2006-03-10 at 12:20 -0500, Philippe Rigault wrote: > > I have two problems with this: > > > > The first is that FC5 will be released essentially _untested_ after two > > of > > its > > > main components were upgraded to a stable release after FC5test3: > > - gcc 4.1.0 > > - glibc-2.4 > > > > It could be argued that FC5 will be _released_ with a stable release of > > its compiler and C library, but not that this had been tested. > > The changes between what we shipped in test3 and what we're going to be > shipping are extremely small. Sure, only 2442 RPM packages have been rebuilt out of 2442. > And we _always_ have to fix bugs in > things between test3 and the final release, sometimes larger ones than > the diff present there. Understood, but there should be a rule that after the last release candidate, there can not be _any_ major change (such as one that triggers recompilation of all packages) and that only major regressions be fixed. And in case a major change must occur (to fix showstoppers only), then at least one more release candidate is warranted. I find GCC to be an example to follow in the way they deal with releases, both in terms of policies and in terms of enforcing them. Release candidates (which test3 should be) are exactly that, an ideal release candidate is one that is not modified at all before release. A (good) consequence of that is that one never knows how many RC will be necessary, all they know is that quality and process is what drives releases. > > The second goes the same way, arguing that if test3 is the latest test > > release, any new major component should _not_ be upgraded to a new > > release, which is particularly true for a big beast like GNOME. > > Again, the changes going in at this point are all small targeted bug > fixes as they wind down their release cycle. > > Trust me, we're looking at diffs of everything that's going in at this > point and if some component of GNOME goes off and rewrites a huge chunk > of how it works, we're not going to pull it in. This point already has 100% of packages different from what I last tested in core3. I trust you and other Fedora developers for the quality of your work, but it is entirely beside the point. The point of testing is that you avoid surprises, and you always apply the same simple rules consistently. My machines trust neither you nor me. Respecting arbitrary timelines for final releases (especially by a few weeks), although desirable, is of importance close to zero to me compared to quality. Cheers, Philippe. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list