Re: Release management and testing problems
Le Fri, Aug 02, 2002 at 05:15:30PM +1000, Anthony Towns écrivait:
> You might want to give some details so the "problem" can be examined. How
> many packages? For how long? Why? What other possibilities are there that
> might not have gotten them stuck?
Sorry I have no log of testing's evolution to be able to give you any
realistic stat for "how many" and "how long".
But I know this happened more than once because I've seen regular
complaints about it and because I've seen it myself in testing's
update output.
But I can give some figures based on the actual update_output.html.
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. 149 of them are considered buggy. 56 of them have
"unsatisfiable Depends". 13 of them are special cases ("no binary on any
arches" because they are udeb or because they are hurd related).
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.
To have a better idea of the possible damage than can do those 354
packages stucked in unstable I have counted all the packages that
are listed in the "Reverse Depends" (as given by apt-cache showpkg)
of them. It concerns 2021 binary packages.
To be honest, this number is too high because that "Reverse Depends"
field also lists reverse Suggests and reverse Recommends. Nevertheless
as you can see, the problem can affect a significant proportion of the
packages.
> > Problem 2 :
> > -----------
> > We upload almost everything in unstable :
>
> This is a statement, not a problem.
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".
If you have any historic log of testing's evolution, I might find real
examples (or I'll ridiculize myself because I've seen non-existent
problems).
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.
IIRC, that was the case with xfree 4.1 ...
> > It's not directly related to testing, but it's more a generic "release
> > management" problem. Most of the free software have stable/unstable
> > branches but we have no such distinction for the state of the
> > packaging.
>
> Likewise.
Yeah, read my explanation to Santiago Vila, it's more a "potential
source of problem" or an area where we have "room for improvements".
It's not something that can be easily predicted, only experience could
tell us.
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: