Re: RFC: implementation of package pools
Previously Eray Ozkural wrote:
> Wichert Akkerman wrote:
> > Perhaps you misunderstand the concept if this thing called `unstable'.
> > It's mean to be *unstable*: the more that breaks there the better it is
> > since it means we will notice and fix it.
> >
>
> Are you sure of this? You can put more relaxed tests for unstable
> than for a more stable release tree.
I'm quite sure of this.
> I think that if you could prevent at least some of the high-severity
> bugs with an automated test suite, it would be a win.
No it would not, that's simply not the purpose of unstable. Unstable
is where the latest and greatest and most broken lives.
> An intermediate release, called "development" or "testing" or whatever
> name is appropriate, would apply stricter tests.
As I said, that already exists in Anthony's testing stuff.
> Stable gets even crazier tests including security tests emulating
> known net attacks, etc. Of course some of this vision might be
> difficult to implement, but it sounds reasonable I guess.
Emulating net attacks? You seem to put way too much trust in testing.
> With the kind of testing I suggest, it isn't.
You're still not understanding the fact that package pools has *nothing*
to do with your testing. Package pools are solely about how to install
a package in an archive, how to make it available to users, etc. What
you install and the tests that might accompany that are a different
issue.
> I bet there are some that does the testing like I describe, for instance
> in Microsoft people write test suites properly[1].
For a company that tests thoroughly they sure manage to produce a lot of
low qualify products. Not everything can be tested, or the test might be
some complex it may not work. And just testing doesn't help as long as
you don't fix the found problems.
> But another success of Debian is I think in the success of "glue" software.
> I propose that bug-finding and package checking gets some more "glue"
> software and gets more automated so that developers run into less trouble.
I haven't seen a good working implementation of a testing setup so far.
There have been one or two proposals that might have developed into
something useful but that's all.
> I have the ideas, but I haven't implemented a filesystem as stable
> as ext2. I would be very interested in writing one of course. I recently
> read a lot of distributed OS papers, and it really seems a very nice
> subject to work on.
distributed OSes as a different beast, and the problems are different.
You might want to look at http://www.globalfilesystem.org/ .
> It is a stupid remark in the respect that you emphasize. Alan Cox is
> my favorite linux hacker. But Linus seems to hold the ropes... Something
> smelling there.
The thing is you don't just need good coders, you need people that are
able to lead others, give a project a direction, etc. For GNU RMS holds
the same role as Linus does for Linux. Not everything likes him,
lots of people have issues with him, but in the end they do accept that
he leads the GNU project.
> No, I don't intend to write a replacement for ext2fs. There're already
> some excited hackers that want to do that. :) I'm very curious about
> the results (like reiserfs going into 2.4, etc)
reiserfs still has some serious data corruption problems to fix; they
have a very interesting filesystem but it's not there yet.
> code that works with g++. it isn't bug compatible
> with any other odd compiler :)
g++ has improved majorly though; g++ 3 will probably be one of the most
standards complient compilers out there.
> If you use it the correct way then it does.
I don't agree with that; in the end this is personal taste.
> You haven't answered to my request on the dpkg.c Could you please
> give a brief overview of the code and algorithm used for satisfaction
> in checkinstallable? I'd really like to review it and contribute
> to the code. Is there a well commented version of it somewhere?
I didn't write or even look at dpkg.c, so I'm the wrong person to
ask.
Wichert.
--
________________________________________________________________
/ Generally uninteresting signature - ignore at your convenience \
| wichert@cistron.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: