El jue, 06-01-2005 a las 13:43 -0800, Will Lowe escribiÃ: > > Is that really true? I would love to run "apt-get dist-upgrade" every > > half a year. Currently it doesn't get me much. :) Now, for production > > systems, don't you do some testing *before* you upgrade the OS? > > Sure I do. But I run a production environment with several hundred > machines in it. We package our in-house software in .deb format to > make rollouts easy. > > I don't look forward to regressing all of that software, and it's > packaging, every six months on a new OS release. It's hard to do that > even every 18 months.
Which will mean that people will skip at least one distribution if we
released each 6 months, even two. That would put the burden on us of
needing to have security support for even 2 more distributions older
than current stable, which could not be possible.
That's why I think that a 18 months release is the best compromise
between server and desktop users.
Other option could be make a splitted release. For example, release
base+server each 18 months and make a debian-desktop release each 6, but
this has also other side effects and implications which are not easily
handled.
IMHO we should focus on these points:
- Having a clear roadmap for stuff we want to include or change
before releasing etch. This roadmap should include things that are
possible to be made in about one year from the release of sarge. Release
managers should agree with that at make it "official".
- A well known date for the freeze. About a year from Sarge release
if we want to release in 18 months.
- A working installer. Now we have one in very good shape. People
working on it should also draw a roadmap of the functions they want to
add in that period of time. The installer should be ready when the
freeze, having some months then to check and polish.
- Keep infraestructure working. What do we need to fix or to
improve? What do we want to change? What do we need when we want to
freeze etch? Waiting for security "to be ready" is a bit discouraging.
- "Release essential" packages should be kept mostly free of RC
bugs. We cannot let those packages to pile up RC bugs. For this,
comantainership and the different teams that have arose recently are
good, so we should push them. They should follow published roadmap.
- For other packages, discourage maintainers to make hughe changes
if not needed, but evolve them. And if those changes are needed, they
should be done earlier in the time. For this, having a "fixed" freeze
date could be quite important. Also, a hard policy for removing from
testing buggy packages should be followed, over all when the freeze
starts. This will need perhaps a utility like "deborphan" but checking
which installed packages are not anymore in Packages file, so people
using testing/released etch could know which packages were removed.
Of course I know that all we are voluteers, and that it is a bit
difficult to enforce a calendar as if we were a corporation, but IMO
having a clear roadmap and schedule make most people to behave following
that, avoiding the free ride period that follow each release, which also
means that a lot of people doesn't remember that release infraestructure
has also te be kept in good shape.
Cheers,
--
Jose Carlos Garcia Sogo
[EMAIL PROTECTED]
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
