Re: New stable version after Sarge
Jose Carlos Garcia Sogo schreef:
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".
I think when you start a new version, we must make some agreements. Like
"everything must be conform LSB 2.0".
I am not sure we need a complete roadmap.
- A well known date for the freeze. About a year from Sarge release
if we want to release in 18 months.
I would say: a well known date for the freeze, and after that the
release as fast as possible (= no date).
- 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.
I think the installer could be a "normal package". We use the latest
release. I think also there could be more then one installer.
- 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.
I normally work in testing, and that seems to work OK most of the time.
I don't see a big problem to declare testing as "frozen", to remove the
latest problems, and then call it "stable".
But maybe I see it to easy...
With regards,
Paul van der Vlis.
Reply to: