Summary of Thread: "Releases"
Note this is forwarded as announced from a discussion on
debian-private. Which took place during release.
Jens
------- Start of forwarded message -------
From: Jens Ritter <jens@hilbert.weh.rwth-aachen.de>
Subject: Summary of Thread: "Releases"
To: debian-private@lists.debian.org
[Note: This is anonymized from posts to debian-private and to be crossposted
to debian-devel within 24 hours! Please send corrections!]
There are some thoughts on changing the release cycle.
* Instead of freezing the current "unstable" tree, it was suggested
to install a "promotion" mechanism, which promotes packages
after some time from broken to unstable to frozen and then to
stable (judged by bug-free-ness or the maintainer).
Here a list of suggested and shortly discussed processes (I hope
this list is somewhat complete):
1) automatic promotion (after some days/weeks of bug freeness,
freeness of bugs of severity "important"),
2) promotion by maintainer (or by periods the maintainer sets in
connection with automatic promotion),
3) using "promotion" only for the first steps in the release cycle and
the current release process for the finalization (stable/CD snap
shots).
4) #3 with a detached "release team" completely in charge of the move
from frozen to stable (release team only has rights to freeze, do
NMU's to frozen, will release official cd's, etc.)
Arguments in favor:
- stops rush of uploads of buggy software when a freeze is in
sight (to get latest version in --- with debugging during freeze).
- Less bugs to be squashed during final stages of release.
- easier making of snap shots which nearly have release quality.
- process involves more developers, so lesser load on the "release
team" (which are currently estimated to be ca. 25 people).
- shorter "penalty" for stable software, due to
- shorter cycle.
Arguments against it:
- "rush" of upload is only marginal, so no problem.
- more people make the process more opaque and this makes the
survey of the process impossible.
- what about dependencies?
- what about different architectures? How to get them in sync?
(proposers think this can be solved, but did not provide
arguments).
- BTS has to track bugs by release and/or package number (=>
rewrite, who will do this?).
- another reorganization of the archives.
- esp. #4 puts high load on release team if it is small.
Instead look into these issues:
- current release process is not "broken", only needs more
communications between the involved parties.
- "release team" must continue work even during non freeze.
- release has to be kept in mind by everyone.
- corner stones have to be announced clearly.
- cd scripts, bootfloppies and other release critical software
should be worked upon all the time.
Outlook:
- policy change necessity, much work to do.
End of summary.
My Comments:
I would really like to see Debian adopt some kind of "bazaar" style
for release --- but without loosing quality. So some kind of mixture
between the current system and the proposed system is what I would
like to see.
But before considering a change first let's dicuss further on how to
handle dependencies with the proposed system:
What happens if a binary incompatible libc is introduced? How will
it and packages depending on it be promoted without inflicting the
state of the "higher" systems (i.e. without degrading the stable
state)?
Unfortunately I became a developer shortly after the move to glibc. So
how was this handled and can this be mapped to the proposed process?
I hope I didn't miss some important points.
HTH,
Jens
--
P.S.: Please vote against Spam! At
http://www.politik-digital.de/spam/
(Sorry Europeans only)
---
Jens.Ritter@weh.rwth-aachen.de grimaldi@debian.org
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37
--
Please respect the privacy of this mailing list.
To UNSUBSCRIBE, email to debian-private-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------- End of forwarded message -------
Reply to: