On Fri, 2006-03-10 at 16:24 -0500, Philippe Rigault wrote: > Sure, only 2442 RPM packages have been rebuilt out of 2442. Um, no. These were rebuilt before Test3, and the reason why Test3 took a while because we wanted to get these built FOR test3 so that they would get TESTING. > > 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 goal of FC5 was to get in gcc4.1. We used pre-release snapshots during the development leading up to the final release. We used these pre-releases as targets that would need the full rebuild so that when the final landed it would NOT necessitate rebuilding the entire distro. See, this was planned out and done with a purpose. We didn't just wake up one day and say "Hey, lets toss in a new compiler sometime in the middle of the development cycle.", this was something we planned around from the get go. Same with gnome. Pre-release snapshots DURING testing to be tested, so that when the final tarballs land, they'll just be fixing bugs and not introducing new features. Funny that. > > > 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. > We're avoiding surprises by using the prerelease snapshots on an, um, prerelease snapshot of Fedora. So that when the final releases come out, we're not surprised by anything, we've been tracking it all along, and we're doing just minor updates for the final release. Does this make sense? -- Jesse Keating Release Engineer: Fedora
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list