On Thu, Mar 08, 2001 at 12:24:29AM -0500, Branden Robinson wrote: > On Tue, Mar 06, 2001 at 11:45:58PM -0500, Ben Collins wrote: > > On Tue, Mar 06, 2001 at 10:31:00PM -0500, Branden Robinson wrote: > > > > > > > * What do you think will be the three major problems Debian will face > > > > over the next year or two? > > > > > > * version skew between our many supported architectures hamstringing our > > > package pools > > > > a) Testing ensures that we can release with little or no version skew > > b) Your assertion makes it appear as if the architectures are at fault, > > when in fact 95% of the time (I have stats) build failures are due to > > the package, and not specific to an arch. > > I do not see how your inference follows from my statement. > > The current implementation of testing does indeed ensure that we can > release with little or no version skew, but it doesn't necessarily result > in less buggy packages. Take the case of XFree86 4.0.2-1. It didn't have > RC bugs, and it didn't have build errors. It just didn't get built for all > 6 architectures for well over a month. Even then, Anthony Towns had to > force it in. (Now, of course, the testing archive has been clobbered and > XFree86 is gone again -- this is so mortifying that my emotional continuum > has wrapped around and I have to laugh about it.)
Releasing is the point, and I do believe that testing will create a more up-to-date release than we have had in the recent past. Just because X (one of the largest builds for the buildd's) had issues, doesn't make it so for all other packages. > > The other 5% can be due to toolchain issues, or just plain old oddities > > in our complex dist that requires the buildd operator to actually > > manually build the package (IOW, no bug at all, just a manual build). > > It doesn't really matter what the causes are. They all take manpower to > fix, and as we try to release for something like 10 architectures > simultaneously, we run the risk of ending up in the same boat we've always > been; testing is so far out of date that it doesn't really matter that it > wasn't that way because we were frozen for 9 months. Of course it matters what the causes are. It is a direct relation to solving it. Fix the bugs in the packages causing them to fail to build, and we have less issues. This is a maintainer issue, not a port issue. We would have this problem even with only 2 architectures. Actually the more archs we have building packages, the more likely we are to see bug reports for common build errors, and the better the packages will be (assuming the bugs get fixed). This isn't one of those problems you can throw people at and hope it gets fixed by shear will power or determination. It is something that needs attention on a singular basis of each maintainer for their package(s). Over the last few weeks I filed almost 100 bug reports for failed builds. These are RC bugs. They were not sparc specific bugs, and generally they were as simple as fixing build-deps, or minor thinko's in the debian/rules (one-liners). Right now, 76 of those bugs are still open, and the packages are still listed as "failed" on my build server, and will remain so until they get fixed. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
