Re: Release management and testing problems
Le Fri, Aug 02, 2002 at 04:27:24PM -0000, Moshe Zadka écrivait:
> > 56 of them have "unsatisfiable Depends".
>
> So, if your idea worked *perfectly*, it would get these 56 in?
In aj's mode :
You don't know what you're talking about, go away.
In my usual mode :
Not at all, those "unsatisfiable Depends" are usually depencies on
non-existent packages. Most of the time the problem is specific to
some architectures (because the dependency is not compiled on
that architecture for example). Those problems happens frequently with
meta-packages because they inconditionnaly (arch: all) depend
on a large number of binary packages and some of them don't exist
on some ports (look at meta-gnome for example).
> > And finally 96 of them are "Valid candidate". The oldest "valid
> > candidate" is 778 days old. The average "stuck time" for actual valid
> > candidates is 84 days.
Those are the packages that are stuck that shouldn't be stuck. The
reason explaining why they are stuck is because one of their dependency
is stuck. Why is the dependency stuck ? Start from the beginning: that
dependency is part of the 354 sources packages stuck.
> I have long suspected the testing scripts can be improved algorithmically.
> However, sadly, I have no time to do it, so I won't comment any more
> until and unless someone who does have time asks me for input.
Share the knowledge ! If someone on -devel likes your idea, he will
implement it. Nobody is going to come and say "I have time, I promise
you to code your idea" ...
> However, "improving the algorithms used by the testing scripts"
> was not, as far as I could see, part of your suggestions.
That's ridiculous. We're not limited to "my" suggestions.
> Basically, what you're saying that if the testing scripts were perfect
> (I suspect that's NP complete and so impossible for all practical purposes)
> and if we had no "unsatisfiable Depends" problems, we could improve
> by less than 50%: in other words, the current situation of Debian is,
> to within an order of 2, *optimal* -- at least as far as the
> whole unstable->testing business is going. Plus, it seems from your
> figures that the best way to improve that is to improve the testing
> scripts.
No, if you read my figures in a sensible way, you'll understand that by
fixing all the RC bugs that are blocking the packages and by making the
packages build on all architectures, you will get away with most of the
actual problems (until the next big update)...
> > This is an introductory statement yes, the problem was described in the
> > paragraph below and it's a real problem. It's one of the worst source
> > of "stuck packages".
>
> Which constitute just 56/10k packages.
We don't have 10k sources packages. And the right figure was 96.
> Now, I want to list the problems (I don't have solutions) I see:
Thanks, go hack on these instead of losing time here ... follow aj's
advice !
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: