On Sun, Jul 10, 2011 at 11:49 PM, Matthew Garrett <firstname.lastname@example.org> wrote:
On Sun, Jul 10, 2011 at 11:11:52PM +0100, Peter Robinson wrote:
> On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett <email@example.com>wrote:
> > It's certainly true that we could do more to identify ftbfs situations
> > earlier, but we've had mass rebuilds in most recent releases. Random
> > failures years down the line really aren't a realistic concern.
> I actually disagree. I've been working on rebuilding F-14 for the current
> softfp arm platform that doesn't need to be boot strapped. The amount of
> packages in Fedora 14 that don't compile on the main intel platform even if
> I do a plain vanilla F-14 install with no updates (ie it was broken on
> release and wasn't any better with any of the updates). There wasn't a mass
> rebuild for F-14, just for perl and python dependencies.
> Even with the F-15 mass rebuild I've found a number of packages that their
> owners never bothered to fix the FTBFS that was a result of the F-15 mass
> rebuild that have caused me problems that I've had to fix because the owner
> of the package never bothered to fix the FTBFS.
Finding that something that didn't build, hasn't been changed and still
doesn't build isn't terribly random
We could do better, but
introducing more mass rebuilds as part of the release cycle isn't going
to make things significantly better when we're already failing to deal
with the fallout from the mass rebuilds we *do* carry out. Fixing this
is a process issue rather than one that's fixed by having FESCO mandate
a mass rebuild after every change that could conceivably cause breakage.
If a mass rebuild causes breakage its a problem which ever way you look at it, the package will eventually be rebuilt and cause the breakage, in my opinion your better off doing that in a controlled manner rather than sweeping it under the carpet and hoping no one will notice.
devel mailing list