Packages with "fc6" name in Fedora 7

[Simo Sorce]

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.