On Wed, Apr 11, 2007 at 09:04:59AM -0400, Jesse Keating wrote: > On Wednesday 11 April 2007 08:31:15 Axel Thimm wrote: > > The fc6 tag is really cosmetics in comparison to what we may run into > > w/o a proper rebuild. In fact we should really keep them (the tags), > > so when a package explodes the user/bug reporter/bug assignee will be > > able to identify the distribution the package was built on and perhaps > > derive that that's the real issue. > > With Koji, it is pretty easy to find out EXACTLY what packages were in the > buildroot to build any given package. The dist tag is not necessary for > guessing. We did have buildlogs with plague, too. I don't know how long they were kept, though, and certainly no user/reporter ever cared to look into them. > All your above scenarios are valid, and can be mitigated by on the side > continuous rebuilds of packages to identify when changes might happen, which > would allow the maintainers and release team to make decisions as to which > packages should be rebuilt for a new build chain. You only test whether it builds, not whether it runs. To continue the bridge-utils example: If it is busted and only shows that it is once you try to setup STP on the bridge, who will teh continuous rebuild show you that? You can only do that by either investing in-house QA for every package update you are going to ship (and we know that these are going to be a loadful per week), or do so in advance during the development/testing cycle. It's just a matter of when it will happen, not if and how much resources it will consume. And I think having it happen during F7testX is better than during F7 package maintenance, or even worse, if it slips the package updating QA and makes it into the proper released updates. Because I doubt that a one-line fix in the ever abused bridge-utils example will make the packager that fixed it to test all aspects of Linux bridging again. > It does not mean we should just blanket rebuild everything just > because we can and there could POTENTIALLY be issues in SOME > packages. If the issues are only potentially, why are you afraid of rebuilding? The arguments were a) too much download volume and b) stable packages. The first argument is void, since the big players consuming 99% of the bandwidth have been rebuilt (for the record, w/o weighing by size FC6 had 80% rebuilt, and the big players were among them). The second argument on stability is also void, since either the package is stable and survives a rebuild, or it is as fragile to not do so. And in that case, we'd like to know before the release, that the package is in a fubar state of affairs. You don't save anything, you just push the problem from the development cycle into the maintenance cycle. -- Axel.Thimm at ATrpms.net
Attachment:
pgpEGfqSVn0tE.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
