Re: [debian-devel] Re: Ancient architecture
Petter Reinholdtsen <pere@hungry.com> writes:
> [Ingo Juergensmann]
> > So, we are currently not in freeze nor was the bug ("too slow building, out
> > of disk space") release critical.
> > There was only an impatient maintainer who complained about a situation that
> > will be handled by the buildd admin. Actually there is therefore no problem
> > to solve. The buildd infrastructure has no problems. There are simply no
> > problems in Debian at all, that need to be fixed.[TM]
>
> Actually, there is a problem to solve. You might not be aware of
> this, but some package maintainers (like me) are trying to make sure
> our packages make it into testing in time. This normally mean that no
> new uplodas are made while a package is waiting to propagate into
> testing (for 2, 5 or 10 days depending on priority), to make sure the
> timer isn't reset, and that all problems detected in the period is
> fixed on the next upload.
Commendable of you. I've seen maintainers upload packages with a typo
fix after m68k was building the package for 50 hours (and the build
then got rejected). That realy hurts.
> When a package fail to enter testing in 2, 5 or 10 days, it means the
> next upload is delayed, and this again mean that the progress for this
> package is slower than it should have been. This in turn make the
> version of the package finally making into the next release lack some
> of the fixes or features it chould have included if the turnaround
> time is getting longer than required.
But the actual build time of a package is not relay important. The
question is how long a package takes from source upload to build
finish. If the package is 3 weeks in the backlog and then builds 10
minutes thats bad. If it builds for 4 days 1 hour aftersource upload
thats perfectly fine.
The current w-b queue tries to build more important packages more
quickly. The base system should allways be more up-to-date than say
kde. The longest delays are usually caused by broken sources or
uninstallable build-depends/depends. The biggest cause for
unneccessary delays is Debians archive scripts, namely installing
binary-all packages before there binary-any companions are available.
> Because of this, I believe it is important that the new packages make
> it into sarge as soon as possible, and every issue slowing this
> propagation should be addressed.
Does that include problems with persons?
> Looking at
> <URL:http://developer.skolelinux.no/info/cdbygging/distdiff.html.gz>,
> I notice that m68k is the arch with the highest number of build
> problems, but this will change over time. A month ago, the "top" arch
> was mipsel. I expect the m68k developers to be able to fix this
> problem shortly, because there are several dedicated developers
> working on it.
Which was when James rejected my buildds and banned Ingos buildds.
Bastian Blank is currently implementing multibuild (a wanna-build
replacement) at full speed and Ingo and I intend to adopt buildd to it
as soon as possible and get the improved system to production quality.
That would mean more buildds for one but also less unsuccessfull
builds and less starving of packages due to a smarter algorithm to
queue packages. Hopefully that gets accpted by all the m68k buildds
and other archs then.
> But the fact that someone is working hard to fix the <arch-foo>
> problem do not change the fact that it _is_ a problem when packages
> fail to enter testing when their waiting period is up. If an arch is
> falling behind, and do not have enough people working on it to fix the
> problems, I do not believe it should be allowed to slow down the
> release process in Debian. If it does seem to have enough people
> working on it, I believe we should let it stay. Do m68k have enough
> people working on it?
M68k has more hardware and more people willing to work on it but the
main obstacle, and I'm sorry to say it but you (James) made the
decisions, is James.
> Check out <URL:http://popcon.debian.org/> if you are interesting in
> knowing how many sarge/sid users on the different archs are reporting
> to popularity-contest. I guess some archs could use more developers
> and users. :)
Hardly conclusive numbers.
Compare to the number of subscription on lists.debian.org. Everyone
subscribe to debian-<arch> is probably intrested in that arch.
MfG
Goswin
Reply to: