Re: [debian-devel] Re: Ancient architecture
On Fri, Mar 12, 2004 at 01:44:10PM -0800, Matt Zimmerman wrote:
> > I guess that the definition of "too slow" here would be that: "such slow
> > that the effort needed to maintain it isn't volunteered".
> > The question of whether a compile lasts 4 days or 40, and whether the
> > resulting binary runs on it is out of scope of the speed decision.
> This is the normal explanation, but I don't think that this definition is
> necessarily useful. No amount of effort can cause the process to take less
> time, and in many cases that is the package maintainer's time, not the
> buildd admin's time. If he needs to wait several days just to find out
> that his package didn't build correctly, to upload a new version and wait
> several days for feedback, this makes his job more difficult.
So what?
If there is no time pressure on release and the package was/is building
fine, than there is no reason to worry about for the maintainer.
Yes, m68k *is* slower than other archs, but that's no reason to complain.
There are people that care about building the packages and there are people
that actually use these packages. If the source upload has been done on time
to get into the release the maintainer has not to be worried if it takes 4
or 14 days to compile on a specific arch. The RM will do that for him
instead, right?
Usually the maintainer has weeks/months/years of time to solve outstanding
bugs of his packages. When he just starts 5 days before the release, you
can't seriously blame the buildd admins for having a slow arch.
There is always some ranting about m68k being slow, especially before
release. Maintainers start to realize that their package is being hold back
to enter testing/release because of bugs, some of them are really old.
And then they start running around, waving with their arms, screaming as
loudly as possible how evil slow m68k is.
My POV for this is:
When m68k would just be there to train maintainers to keep an eye on bugs on
other archs than their favorite $arch, then m68k has an excellent
justification to exist.
> A better question is whether the end result of all this effort is actually
> useful. One metric by which usefulness can be measured is, "is anyone
> actually using it?". In the case of m68k, it is often possible to
> demonstrate that the result is unused, because it is unusable.
Users tend to use programs that are available. So, when there is no
installable package, no user will likely use it at all.
That's some sort of argumentation as for WMD in Iraq: Saddam has WMD, but we
can't find it, because they are hidden too well, so Saddam has to prove that
he has no WMD at all. How can you prove something that you don't have it
which you actually don't have.
Basically it's up to the user to decide if he uses a package on a certain
arch. It's the task of the buildd admins to ensure that he can install as
many packages as the user wants to install. It's the task of the package
maintainer to handle bug reports for his package and keep the packages in a
good shape.
--
Ciao... //
Ingo \X/
Reply to: