Re: RFC: implementation of package pools
erayo@cs.bilkent.edu.tr (Eray Ozkural) wrote on 22.10.00 in <39F32AB8.3EAF1023@cs.bilkent.edu.tr>:
> Are you sure? As far as I've seen, things including the recent libc
> breakage could be avoided if there was a testsuite that ran automatically
> _before_ packages got uploaded. For instance, exim is considered
> to be an important subsystem, when libc6 is to be checked for
> upload all packages dependent on it have their test suites run... In
> such a case, exim would fail the testsuite, indicating that a breakage
I'm trying to think of an automated test that would have caught this
particular problem. Preferrably one that could have been written before
the problem occurred.
You know, I can't actually think of one.
The way to get exim to fail is upgrading a system with a *running* Exim
demon which actually handles mail, and to analyze the failures that happen
after the upgrade because Exim's DNS usage breaks.
That's something for a human to do, not for a testsuite.
Which means that while automatic testing is certainly a nice thing to
have, in all probability it wouldn't have caught this problem.
> would be expected.. and consequently the system would decline upload
> of that package. I'm sure that major OS vendors have been using these
> procedures for many years. It's a sound software engineering practice.
I'm pretty certain *nobody* has an automated testsuite that would have
caught *this* error.
> > > ext2 sucks by the way. I wish I had some free time to teach those
> > > arrogant guys on the linux-kernel list how to write a robust fs.
> >
> > You're even more arrogant. They know perfectly well what the good
> > and bad things are about ext2.
>
> Why haven't they been able to fix it for years then? Anyway, if you
Because that's a hard problem, and there are lots of other important
problems to solve?
> find me arrogant, it's okay. But everybody on that list seems to
> be a fan of Linus and Alan, a repulsive circumstance for any new
> linux developer. It's like a strict hiearchy, very different from
> what goes on in the GNU project where people favor work done instead
> of reputation.
Umm, if you look a bit more closely you might realize that the reputation
in question is the *result* of work done.
And, well, "the GNU project" and "work done" as a contrast to Linux kernel
work ...
Let me put it like this: there are projects under the FSF umbrella that
are similarly productive as Linux. Those are not typical FSF projects,
however. The FSF in general is better known for working slow as molasses.
As for "strict hierarchy", well, that is *not* different from how the FSF
is run. Of course, the only strict part wrt. Linux is that Linus is the
only person who decides what goes into the official kernel (well, it *is*
his baby), and he'll usually listen to solid arguments, more than most on
linux-kernel.
> I didn't know you were the author of ext2fs *<:) I don't see why
> you're offended by my reaction to ext2fs when given as an example
> for good software.
Maybe he just disagrees with your comments. I do. I've used (as in, for
important applications) Apple DOS 3, CP/M 2, UCSD p-System, MS-DOS FAT and
VFAT, Netware TurboFAT, Apple HFS, NTFS, OS/2 HPFS, VM/CMS, Linux ext2,
and probably some more I forget, and I'll claim ext2 is actually the best
of that bunch for practical applications (which includes crash recovery,
which is incredibly good for ext2, and incredibly seldom actually needed).
MfG Kai
Reply to: