[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: