Release and maintenance cycles [was: Re: Bug 0 review pls]

[Dan Shearer]

On Sat, May 31, 2008 at 04:59:10PM +0100, Matt Darcy wrote:

> A core issue for me with Ubuntu's server model is Ubuntus release model 
> in general. A release every 6 months is not a model that can be pushed 
> beyond home servers or work group services. This is for multiple reasons.

Microsoft often includes major functionality with service packs that are
in effect an OS upgrade, and large customers treat them that way too. In
your opinion does this moderate the degree to which Ubuntu is very
different from Microsoft? But yes, 6 months is aggressive.

> 1.) a business of any nature cannot be expected to upgrade one server - 
> let alone a multiple server estate every 6 months, throwing the LTS 

I don't think Ubuntu Server expects its users to upgrade every six
months. Your points add up, I think, to an observation that Ubuntu
Server is making it difficult not to upgrade by failing to provide good
long-term stability. 

> For me the server model needs to move away from 6 month release 
> windows to gain any sort of credability in the business market.

Well I'd have to say I didn't think 8.04 was ready to be LTS, and if it
had not been I think corporate users would quite possibly have just
ignored it and waited for the next one. Presumably it was pulled along
by the need to keep the brand together, and Desktop was committed to a
release. 

Ubuntu Server has almost no technology in common with Desktop. The links
are in the people behind the two OSs who are connected in many ways, and
in branding. To me this is not a strong case for keeping the two OSs in
the same release cycle in terms of LTSs. Outside the LTS designation,
six months sounds fine to me.

There is an engineering difference between Desktop and Server as well.
Because Debian is not a very good corporate server in the Bug0 sense
there's a good deal more more to be done by upstreams and with upstreams
over the next 12 months. For an initial cycle of "we're getting serious"
I don't think a 3-month development sprint is ideal. Getting the first
levels of integration in place with software stacks that have never
found a need to be integrated before is not something to rush. Next time
around, quite possibly.

> 2.) LTS fixes and backports. There is no enough fixes, updates and 
> upgrades to make LTS a viable long term (3 year) stratergy for business 
> use. Too much focus is on "fix for next release" or "upgrade product for 
> next release", which relates to point 1. 

We have a case study of what happens when enormous resources are thrown
at keeping things stable. I'm referring to Red Hat's excellent kernel
team. Jon Corbet wrote about this at http://lwn.net/Articles/239036/ .
The kernel is a kind of limiting case, but the backport issue is the
same in principle elsewhere and needs very careful management. Ubuntu
has nothing like this level of effort available. It would be very
helpful to see a strategy for addressing this difficult issue.

> The 6.06 release was crippled on later edition dell servers due to the
> lack of back ports on the kernel for specific hardware controllers, if
> the LTS edition is to be truly LTS, then I'm afraid kernel
> updates/back-ports will need to be on the radar more, and things
> learnt from the non-LTS products need to be pushed back.

Continuing on the same theme,  for server kernels a lot of lessons
should be learned from RedHat. They do a very good job, and the way I
understand their process it centres around formalised testing. That
costs money, there isn't a way for any community to take the lead on
this that I know of.

> 3.) the 6 month release cycle from my experience is a real blocker for 
> major corperate application players (Oracle being an easy example) to 
> get on board and help make Oracle (again as an example only) a supported 
> platform on Ubuntu Server. It's all very well having great lamp 
> applications available to Ubuntu, but a few corperate big boys need to 
> have their product on Ubuntu to be a realistic option for larger 
> businesses.

That's one vector. 

Another vector is that in Linux, anyone's Linux, there is no such thing
as "great LAMP applications" in the Bug0 sense.  Install Microsoft
Sharepoint and see what I mean: part of Sharepoint is a set of web apps
that have LAMP equivalents and the level of integration is something
that LAMP apps haven't begun to touch. From LAMP apps we can generalise
out to other common applications. How easy is it for a Linux admin to
have a network where removing a user from a group in LDAP/AD will see
that immediately honoured by email servers, web cache, file services,
instant messaging, desktop application and email/voicemail addressbooks?
Sure you can set it up if you know what you're doing and you have a lot
of time. But Linux application stacks just aren't integrated. 

In my view Ubuntu Server needs to be talking to more upstreams saying
"here's how we'd love to see you integrate, are you willing to be a part
of this?"

ALl of this needs a one-off bootstrapping process, and a 3 month
development sprint doesn't match.

> I have very little issue pushing RHEL (apart from cost) or Centos to
> small, medium or even Large businesses but I do have issues pushing
> Ubuntu.

On a positive note then, the way I view Ubuntu Server is a product
without a personality. It doesn't stand for anything yet, it is too
unformed. That means alone of all the brand-name distros with a server
version, Ubuntu has the chance to get things right. The other five have
to live with their own history, and all of them have some ugly bits in
that history :-)

-- 
Dan Shearer
dan at shearer.org