Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 5:16 UTC (Fri) by mikov (guest, #33179)
In reply to: Manoj Srivastava resigns as Debian secretary by dlang
Parent article: Manoj Srivastava resigns as Debian secretary

The stable tree does matter a lot! In fact I love the stable tree and the fact that Debian doesn't have a release every 12 months. We all have more important things to do than perform OS upgrades.

If you ask me, an OS upgrade that is more frequent than 24 months is unproductive. I simply don't have time for that crap. So, I honestly do love Debian's slow releases.

(Plus, one has to ask oneself - how do the other more "frequent" distributions manage to fix all bugs so much faster than Debian in order to release? The obvious answer, which I have alas suffered through, is they can't and they ship with more bugs)

BTW, we manufacture appliances which run Debian (with some non important customizations). We always stick to stable, so we have it on our development machines and on our target hardware. It would really suck if we had to change everything every 6 or even 12 months. As it is, we have an OS that matches our business model perfectly. We could be in the minority though...

(We have considered Ubuntu LTS and it would probably work for us, if Debian disappeared, or, God forbid, started making more frequent releases)

Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 5:36 UTC (Fri) by dlang (guest, #313) [Link] (7 responses)

IMHO the best situation would be to have releases every 6-12 months, but have support for old releases long enough so that you can choose to skip a release (or two) and still have a couple of months after the latest release comes out to test it before having to move.

every distro makes mistakes at some point, having the ability to say "I don't like the choices that you made for this release, I won't upgrade to it" without loosing support before the next release is a _very_ nice position to be in

by the way, rapid releases don't nessasarily mean buggier releases. if you are making releases more frequently, the number of things that change from release to release is smaller, so it should be easier to stabilize the release. the key to making the rapid release cycle work well is being willing to say "your new version isn't ready yet, it doesn't go in this release, we'll try again next time". If you have rapid releases this isn't that big a deal, if you have slow releases anything that doesn't make it in this release will have to wait a _long_ time.

I use Debian on servers and firewalls where I am willing to have the core outdated in the name of stability, but am also willing to compile my own versions of the few programs on each system that really matter. for desktop systems where there are a lot more programs where the updates matter (and a lot more interdependance between component versions), Debian is a horrible choice. for that I need something that releases more frequently.

Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 6:07 UTC (Fri) by mikov (guest, #33179) [Link] (3 responses)

"""
for desktop systems where there are a lot more programs where the updates matter (and a lot more interdependance between component versions), Debian is a horrible choice. for that I need something that releases more frequently.
"""

I don't know, man... My experience is actually the opposite. Having the non-LTS version of Ubuntu on a development machine has been a nightmare. Days of wasted time, failed upgrades, etc. Rinse and repeat every 6 months. I can't even imagine what a "regular" person would do if they had it at home. Upgrade every six months? Really?? Come on! Do "real people" actually do that?

I feel pretty comfortable with Debian stable and backports. I think it would help a lot if backports were supported "officially".

I always compare the situation to Windows. You practically never upgrade the OS there.

Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 6:22 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

many people do upgrade every 6 months. many of those people wait a few weeks after a release is made before doing the upgrade so that the biggest isues can be found.

with Ubuntu you have the option of upgrading every 6 months, every 12 months, or every 18 months without loosing support (other then in the time between the release at the 18 month mark and the time you move to it). this is ignoring the LTS releases.

in practice people either upgrade at the 6 month point (if they are looking for some new feature) or at the 12 month point (at that point there are almost always new features you want, plus it give you testing time before loosing support)

Fedora has a 12 month support cycle with a 6 month release cycle, that means that to remain supported they need to upgrade every 6 months (or 12 months with a small gap in support)

people running gentoo or debian testing/unstable tend to upgrade far more frequently (monthly, weekly, or sometimes daily). it helps that these two distros do a pretty good job of upgrading seamlessly. as I noted above, this sort of upgrade cycle is not suitable for larger installations.

in my opinion about every year is the sweet spot between constant upgrades and missing features for relativly fast moving evnironments like desktops

Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 15:53 UTC (Fri) by mikov (guest, #33179) [Link] (1 responses)

"""
with Ubuntu you have the option of upgrading every 6 months, every 12 months, or every 18 months without loosing support (other then in the time between the release at the 18 month mark and the time you move to it). this is ignoring the LTS releases.
"""

I did not know that. How does it work out in practice - do they provide security support for two non-LTS releases back? Can you upgrade directly from release-2 to current, or do you have to do it in stages? The latter would be a major pain.

BTW, I am not sure that I agree that "regular" people upgrade every 12 months. The "regular" people who I know (e.g. my wife), if they used Linux at all, wouldn't want to upgrade ever. In practice they wouldn't be able to perform even a single upgrade anyway - almost none of my own Ubuntu upgrades have been completely trouble free. Perhaps a paid support contract from Canonical would help there, but $250/year may seem pricey...

(Of course the same problem applies to Windows too - when my wife installed Vista's SP1 on her own on her laptop her sound stopped working and the screen reset to 640x480, which actually prevents you from seeing the "OK" buttons of most dialogs :-)

Ubuntu upgrades (was: Manoj Srivastava resigns as Debian secretary)

Posted Dec 25, 2008 8:47 UTC (Thu) by TRS-80 (guest, #1804) [Link]

I did not know that. How does it work out in practice - do they provide security support for two non-LTS releases back? Can you upgrade directly from release-2 to current, or do you have to do it in stages? The latter would be a major pain.

Non-LTS releases receive 18 months of security support, however upgrades from release-2 to current has to be done in stages. LTS releases get 3 years of desktop support and 5 years of server support, and you can upgrade directly from one LTS release to another.

There are some caveats with this: the upgrade process, particularly LTS to LTS, is pretty fragile compared to Debian, which has very smooth upgrades thanks to the daily upgrade testing provided by testing and unstable. The other is support is only guaranteed for packages in main, which is fairly limited, and the stable release update (SRU) process is very slow.

Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 6:25 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

"IMHO the best situation would be to have releases every 6-12 months, but have support for old releases long enough so that you can choose to skip a release (or two) and still have a couple of months after the latest release comes out to test it before having to move"

Fedora lifecycle has a similar goal. Refer

http://fedoraproject.org/wiki/LifeCycle

Manoj Srivastava resigns as Debian secretary

Posted Dec 19, 2008 7:47 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

that may be the goal, but a 6-month cycle with 12 months of support ignores the reality that it takes time to test a new version, then schedule and perform an upgrade (in a large organization the upgrades will be phased)

it can take a couple of months to do this, even when everything goes perfectly. as a result fedora's schedule really requires an upgrade every 6 months to each new version.

6-month cycle with 12 months of support?

Posted Dec 26, 2008 14:05 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Here at the computer lab we do just fine with Fedora, updating regularly around once a year. Sometimes (if the new bling-bling is shiny enough, and terms allowing) we do update mid-year too. Yes, while all this goes on select machines are running the next version (or even rawhide) for testing. Servers here are on CentOS: Very similar in how they are managed, mostly compatible; but need not be upgraded so stringently (in any case, latest software isn't so much a need here; besides, we mostly upgrade soon after a new CentOS comes out, but it is reassuring to know that you can take your leisure at it).