Development workflow.
On Mon, 24 Feb 1997, Malc Arnold wrote:
> 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.
This is essentially what liw proposed (see the list
archive for his proposal): Have an intermediate "tested" distribution.
So instead of packages going from unstable to stable. They have a path a
bit longer:
(dinstall) (testers) (release)
Incoming => unstable => tested => stable.
Essential bug fixes can still show up immediatly into 'unstable' but it
will require some additional time before they show up in 'tested'.
This kind of organisation could shake out *many* bugs, but it will
require a lot of testers too...
Cordialement,
--
- ** Linux ** +-------------------+ ** WAW ** -
- vincent@debian.org | RENARDIAS Vincent | vincent@waw.com -
- Debian/GNU Linux +-------------------+ http://www.waw.com/ -
- http://www.debian.org/ | WAW (33) 4 91 81 21 45 -
- | Luminy (33) 4 91 82 85 32 -
---------------------------------------------------------------------------
--
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: