Re: Release management and testing problems
On Fri, 2 Aug 2002, Raphael Hertzog <hertzog@debian.org> wrote:
> We have 354 source packages that are stuck in unstable for more than 30
> days (calculated with a hacked grep-excuses script taken from
> devscripts). 134 of them are out of date on at least one
> architecture.
So, no amount of trying short of improving buildds or similar can solve
them, huh?
> 149 of them are considered buggy.
So, we don't *want* them in testing, do we?
> 56 of them have "unsatisfiable Depends".
So, if your idea worked *perfectly*, it would get these 56 in?
> 13 of them are special cases ("no binary on any
> arches" because they are udeb or because they are hurd related).
Let's leave these special cases alone.
> 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.
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.
However, "improving the algorithms used by the testing scripts"
was not, as far as I could see, part of your 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.
> 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.
> Anyway, each time we do one major upgrade on perl/xfree/gnome/whatever
> we have big dependency problems ... that's why you have to force
> packages from time to time into testing in order to "deblock" the
> situation. But you deblock it only when the blocking package is mature
> enough for testing. In the mean time, many packages are stuck in
> unstable.
Summary: "major upgrades are done by hand, and up to RM discretion".
-------------
Now, I want to list the problems (I don't have solutions) I see:
* No always-working CDs and installer
* No testing security updates
* 144 RC Bugs in Testing - how did they get there?
I understand aj to want to be able to say, at any random time, "release!"
and have to do nothing beyond change symlinks and send out the announcemnt.
As far as I can see, if these three problems are solved then this can
be made reality.
The first, as far as I know, is being worked on by the debian-installer
team. The second has infrastructural support -- I don't know what
we need beyond that. More people in the security team? Something
else? Could someone from the security team comment?
Part of the reason for the third problem are known deficiencies in the
BTS. Serious bugs getting tagged RC (old problem, see Branden vs. Anthony),
bad tags, people filing bugs with high severity for no reason and
the security updates problem. Also, it would be nice if testing_problems
actually linked to the bugnumbers, since (and this is another problem)
if a bug is fixed in sid, it is marked closed, and eventually vanishes
from the BTS (yeah "archived") while a "sid" tagged bug keeps the
package out of testing.
Reply to: