On Tue, Apr 10, 2007 at 10:41:07AM -0400, Jesse Keating wrote: > On Tuesday 10 April 2007 09:33:29 Axel Thimm wrote: > > 1 100% > > 2 99.7% > > 3 100% > > 4 96.6% > > 5 99.991% > > 6 95% > > 7 80% > > > > So as you see, up to F7 Core had really been effectively rebuilt on > > each release with FC4 and FC5 being the most "sloppy" ones leaving > > 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild > > rate. This *is* a new release model. > > What I'm saying is that these numbers often happen naturally instead of forced > by a full rebuild. _That_ is the model that hasn't changed. OK, still the packages were all more or less rebuilt, and sometimes the packagers comment this as a simple rebuild for the upcoming release. Which means that while there was no mass-rebuild, many packagers in RH decided to do so on their own when the time came. For F7 the policy obviously changed, otherwise there wouldn't be a sudden drop from 95-100% to 80%. > The ONLY time we've done a forced rebuild is for technical reasons > and NOT for arbitrary reasons like "hrm, this is test2, maybe we > should rebuild everything just for the hell of it" or "there is a > lot of disttags that haven't been updated, lets do rebuilds to reset > them, that sounds like a good idea...". Forget about the disttags, the discussion started about them, but this is not about cosmetics. They only indicate the problem which is that some packages have not been rebuilt. I'm personally against rebuilding just for the fun of nice disttags. But I'm all for rebuilding where it makes a technical difference. Some userland utils depend on kernel-headers, that has changed and in doubt all such dependent packages would require rebuilds or a review. Furthermore glibc has changed in various places among other some sys/personality stuff and kernel 2.4->2.6 bits. Any package that required 2.4 compatibility in this area is now busted (don't remember whether it was sys/personality or something else, check the diff). And who's going to check which packages where using these glibc headers to enforce a per-package rebuild? And this is just the surface scratched. If someone invests more time, he will come up with more dependencies that may now be broken or not, and finding that out takes more developers' time than a simple rebuild-all-and-test-the-outcome model. > Rebuilding for technical reasons is fine, relying upon throwaway > rebuilds to find said technical reasons is strongly encouraged. Ask yourself why they are being thrown away. If there really is no technical reason to rebuild a package, then the rebuilt package can't be broken or less stable that the "old" one. By throwing them away you never have the chance to actually have them tested by a wider audience (or any audience at all). Placing the rebuilds into rawhide instead will really show whether the rebuild was worth it or not, e.g. when things start to break, and you get a change in fixing them. Now we will only get that chance when a package is rebuilt for other reasons post-release, e.g. while adding a security fix. And imagine the confusion of the packager that only changed one line in foo-1.2-3.fc6, successfully rebuilt it to foo-1.2-4.fc7, and the package does not run. Because that scenarion will happen, Matt checks for build errors, so the build will succeed, but the more intricate runtime bugs will only surface when you have the least time to deal with them. And the horror scenario is that since it was a one-liner fix it will get less testing and make it into updates-released being half-broken giving Fedora negative publicity. In short: It's better to have these packages break and fix them during the development/testing cycle than during maintenance. > Picking arbitrary points to forcefully rebuild everything is not. Not an arbitrary point, but at "freeze time" (personally I would rebuild for each test release, but rebuilding once at freeze time would be enough). And again: This has nothing to do with rectifying disttags and cosmetics in the package name, they are for now just an easy metric to see what was rebuilt, and when. And if we'd decide to go for full rebuilds, disttags would be a tool to get 98% done w/o a sweat. But still they are not the problem, they might become the solution instead. -- Axel.Thimm at ATrpms.net
Attachment:
pgptgw9U9hAks.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
