On Wed, 2007-04-11 at 15:20 +0200, Axel Thimm wrote: > 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. +1 your arguments are rock solid imo! Simo. -- 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
