Re: Release management and testing problems
Raphael Hertzog wrote:
> 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. :-)
It's almost impossible to read a list like this one without providing
solutions here and there, so please forgive me for doing so :-)
> 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).
Yes, packages should be compiled using libraries in testing. I fully
agree, since it would help to solve the following
related problem: Currently there is no way to ensure that
build-dependencies are met in testing. The testing scripts only check
for ordinary dependencies to be met.
> [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 ...
A similar problem is that packages are sometimes stuck in incoming
(not even unstable) because they require the override file to be
edited first.
> 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)
> [...]
>
> 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]).
Yes, build daemons should run testing...
> - packages well tested (eg: a package that was in stable where a simple
> documentation fix has been made)
IMHO, this is a pseudo-problem. You can take a package in stable,
apply a documentation fix and upload it for unstable, and yet the
resulting package may differ greatly from the one in stable, since
the compiler version and libraries may well not be exactly the same.
If it's really true that the fix is harmless, and the previous version
is already in testing, there should not be any reason why the new package
should be stuck in unstable for more than ten days.
> 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).
I don't see a problem here either. We package the stable branch, since
our goal is to produce a stable system.
We should never run the risk of the stable version in testing being
replaced by the unstable version in unstable, because that would be
contrary to our goal of keeping testing in an always releaseable state.
If we want the unstable branch to be also available, we can use the
experimental distribution, or package it using a different name.
Reply to: