[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Release management and testing problems



Hi everyone,

following Anthony's advice, I suggest to list all the problems we have
noticed with testing and the way we manage release.

I'll give you the problems that I have with testing, I invite you to
complete the list with problems that you had. Do not provide any
solution at this time ... we'll think about solutions later. :-)

If you had one of the problem mentionned, feel free to give more
information about it (if you find that problem very annoying or not,
and so on).


Problem 1 :
-----------

Some packages are stuck in unstable because one or more of their dependencies
are stuck in unstable[1] even if the package itself would perfectly work in
testing (if it had been compiled against testing libs).

[1] The reason why the dependency is stuck doesn't matter. It can be
that the packages is updated too fast to have a chance to get in
testing, or a RCB not fixed because the maintainer is MIA, or a problem
with autobuilding, or anything ...


Problem 2 :
-----------

We upload almost everything in unstable :
- pre-releases (alpha/beta/release candidate/cvs snapshots)
- new packages not well stress-tested (ex: any big package in its -1
  version)
- packages well tested (eg: a package that was in stable where a simple
  documentation fix has been made)

All those packages are treated the same way in unstable. It appears to me
that "prerelease" and "new packages not well stress-tested" are packages
that are likely to need several updates and are thus unlikely to go in
testing soon. Nevertheless they are in unstable and they are used when
building any package in unstable ... that's how they can easily become
the packages that are blocking other packages (that I mentionned in
[1]).


Problem 3 :
-----------

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. The distinction unstable/stable is a decision made by the
author. The only distinction in the quality of the packaging that we
have is unstable/testing (i'm completely ignoring "stable" since it
is not changing except for security updates) and the maintainer is not
much involved in that decision (which is taken by the scripts).


Cheers,
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com



Reply to: