Re: Why not to use CVS
Hi all,
My note on the CVS and pre-release testing issues from Debian-private.
(This mail is to be found on debian-devel since I think it's a more
appopriate forum).
On 23 Feb, Bruce Perens wrote:
> [Snippage]
> I'd prefer the workflow go this way:
>
> 1. Maintainer uploads source and binary package
> 2. Testers test package.
> 3. Testers submit bugs/patches to maintainer.
> 4. If package doesn't have known bugs, or if it's an improvement on
> the previous version and its bugs are non-critical, package is
> moved to the "tested" distribution.
> 5. Maintainer reviews bug reports and merges in patches.
> 6. Go to step one.
>
> [Snippage]
> I would prefer to keep the maintainer in charge of any changes to the
> program throughout the entire process.
I think it might be a good idea to look at the "package life cycle"
here. As far as I can see there are two situations where packages
are most likely to have serious problems:
1. The first time the package is uploaded, especially if it was
built by a new maintainer (like me).
2. When a new upstream version has been released.
The theory here is that upgrades where only the Debian version changes
(or the minor version of a Debian-specific package) are likely to be
(hopefully-small) bug-fix updates, where a specific set of problems is
addressed. New upstream versions, and *especially* new packages, will
contain much more sweeping changes, and are much more likely to have
bugs. So why not target the attentions of the testers to the areas
where they are most essential?
So how does a package life cycle like this sound?
1. Source and binary of new package uploaded.
2. Testers test package and file bug reports.
3. Maintainer fixes the testers' bugs.
4. Goto 2 until testers ok package (or maintainer gives up ;-).
5. Package released into normal unstable -> stable cycle.
6. Maintainer fixes bugs and releases updated packages
7. Goto 1 when the upstream version or maintainer changes.
The main problem I can see is that this might slow down the release
of essential upstream fixes (like the recent inn security bug). If
we feel this is the problem, then we could skip the requirement to
retest a package after the upstream version (but not the maintainer)
changes. We'd probably want a mechanism for flagging any critical
bugs in existing packages, which require that a new version be
uploaded right now, regardless of any other considerations.
As a new maintainer, I do feel that packaging anything non-trivial for
the first time is a bit like running a system without a backup.
There's no "safety net" there with the current setup; if I make a
stupid mistake, or misread the manuals or policy document, it's quite
possible that the first person who notices the problem will be an
end-user. This does cause a certain nervousness (which is probably a
good thing); especially when you consider that package maintenance is
complex enough that it's fairly easy to make mistaiks.
Comments welcome (roughly translated: please knock down my straw men).
--
M a l c . . . | "A wrong parameters may be caused the mainboard
(malc@thing.demon.co.uk) | out of order." -- Pentium motherboard manual.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: