Re: Release management and testing problems
Raphael Hertzog (2002-08-01 18:14:47 +0200) :
> 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).
I consider that to be a feature, not a problem. Packages are stuck in
unstable for a reason. This reason is implemented as a set of scripts
(of which I plainly agree I have no knowledge). This reason is meant
to keep testing an almost-releasable, coherent distribution. No, I'm
wrong, it's meant to be a freezable coherent distribution. Packages
compiled against testing are packages you *know* will be *broken* when
the packages they depend on enter testing. You *know* you will have
to recompile for the first dependency entering testing, then wait
until your package enters testing again, then recompile again when the
second dependency enters testing, then wait, etc. That means the
package has to wait for its probation period several times instead of
once.
I do not know if what you refer to as Problem 1 was actually a
design goal or not, but if it was, then I agree with that design
decision.
> 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]).
This is not a problem that lays in the reach of release management.
This is not a problem that is related to testing. Insofar as it is a
problem (I'll assume your problem is "packages block others from
entering testing"), the solution lies not in a change in the way
releases are managed or on the way testing works, but in where to
upload. Experimental exists for a reason. *-snapshot and *-cvs
packages exist for a reason. That's two solutions to what I assume
you mean by your statement of Problem 2, none of which involves either
release management or the way testing works. Besides, the "stable
with a simple documentation fix" case does not cause problems, does
it? The package will enter testing in a fairly straightforward way if
the fix was that simple.
> 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 disagree. The maintainer has two ways to reflect the way he
regards his package (uploads to the experimental distribution and
*-{unstable,cvs,snapshot,whatever}). The distinction between testing
and unstable is indeed not taken by the maintainer (although he can
influence it a bit by way of retarding an upload or submitting a
release-critical bug). It is taken by our users, because testing aims
at providing a coherent and working distribution for our users. The
testing scripts take their decision based on bug reports from our
users. Again, I'm not sure exactly what Problem 3 is for you, but if
it is that maintainers have no way to maintain two branches, then it
is a false problem since two solutions already exist for it. If it is
that maintainers have little control on what enters testing when, then
I consider that to be imposed by a design goal.
\end{boring-rebuttal}
To sum it up: I consider your Problem 1 to be a design goal, and a
good one, not a problem. Problem 2 is unrelated to release management
or testing. Problem 3, insofar as it exists, is a necessary way to
achieve a design goal.
I do not agree with your Problems 1 and 3.
I do agree with your Problem 2. One solution at least seems rather
simple in its principle: promote experimental, promote *-snapshots
packages. We'd have to find extra ftpmasters to cope with the added
number of packages, though.
I know your proposal: a new testing-proposed-updates distribution,
where packages are compiled against testing. I strongly disagree with
the second part of it, and I don't see the point of the first part
since we already have experimental.
Don't get me wrong. I'm not implying that testing is perfect the
way it is, or that the release management couldn't be made better.
The current way of blocking a package from entering it feels
unnatural. It's sometimes hard to know why some package is blocked in
unstable. It's sometimes frustrating to see that your package is
locked out because of a build failure on an architecture you've never
heard of. But I consider these problems to be rather what we could
call "bugs in the implementation" than "design flaws". Missing tools,
missing features on the tools, etc. Not a major problem with release
management.
Roland.
--
Roland Mas
ar c t e l l iè u ai i a mi .
-- Signatures à collectionner, série n°1, partie 2/3.
Reply to: