Re: time-based release freezes
Hi, Stefan:
On Saturday 05 September 2009 17:27:22 Stefan Krueger wrote:
> Hello Debianteam,
>
> I hope you understand my terrible english ;)
>
> It is the fixed release cycles, my opinion ist that 2years are too short,
> because Debian is used more as a server operating system, the people how
> would like an actuelly version of an program can use Debian testing.
Don't be fooled by the fact that Debian's internal development is made
completly public: the only public "product" from Debian is "Stable";
everything else are "development tools" so telling "if you want to use
something more current, you could use Testing" is not an answer; you should
say instead "if you want Debian to be released more on time and with higher
quality you could help by using Testing".
>
> I would make every 3years a feature freeze and every 1.5 years a
> "stable-and-a-half", then the topicality also ensures version of Debian
> (kernel, Xorg, etc).
So you advocate for a 3 year release. You are aware that with a 2 year
release and at least one year of warranteed support for oldstable you already
get your 3 year release "for free", don't you?
> The old stable, must be supported for 6years, has been published until the
> new version(testing to stable)
You mean for a grand total of nine years? If that's your point, are you aware
that this would mean supporting up to eight different versions at any given
point in time (four releases plus four stable-n-half)? Even with a three
years grandtotal that would mean four to six releases.
> I hope I could possibly give one food for thought ;)
The food for mind is: where are you going to get the manpower from? And I
mean the absolute manpower and the relative effect it will take on developers
knowing that their efforts only will be seen on a three year timeframe and
that most of their efforts will go to support "old, boring versions from
almost a decade ago". It's my bet that if you tried to go that path you not
only would lack the manpower now but that the project would lose manpower on
the long run.
Of course I would want Debian's support "for the most current software by the
day I happen to deploy a new service -still it should be rock-stable; and
then it would have to be supported for as long as I happen to want that
system running, be it one year or a decade", but you need reality into
account: even those like Red Hat that offer "long time support" do it by
means of point-releases that in fact are different systems: they change
behaviour on the way -and I've been bitten for such changes in the past, and
their "support" for some of those changes are "upgrade to latest point
release; you will have to test if any change behaviour is a problem on your
environment on your own".
I feel for my systems that two years between releases is just a bit too short
for my taste on average but too long on fastly evolving services but I feel
is quite a reality balance on average, having two years plus at least one
year window for upgrade planning.
As long as upgrades continue to be as sweet as they are now, I find the burden
acceptable but there are problems that need to be taken care of: new hardware
and services exposed to external interaction (currently they try to be taken
care of by means of release-n-half kernels and volatile repo, but probably
more thought and effort could go on this side).
After all if you really *need* the long support (which is boring and
expensive) corporations are known to be good on that part (money for
boreness): you can go with Red Hat or if you really like "the Debian way" you
can get it from Canonical (and you can push Canonical with your money if you
feel they derive to much from Debian).
Reply to: