LTS and release methodology

[Luke L]

Hello. In my defense, some of the errors in my essay are due to the
fact that I was new to Ubuntu at the time, and since then I have seen
the effort and complexity of the project. I have also been around the
wiki, and yes, I see that 10.04 is the next LTS :) My freshness to the
subject is the reason that was not posted on a mailing list when I
wrote it.

I agree with many of your points. I now understand things that are
quite clear to people once you really understand what Linux is all
about.

For example, the fact that a distro is only a set of tools and
programs developed by third parties, integrated by the OS team. That
said, errors in those programs are not solely the responsibility of
Ubuntu. However, regression is still regression, and I still find it
odd that a perfectly functioning version of a program can get
"upgraded" to a version with new errors! I know it's a tough job, but
it is still a problem.

Software: I know that newer is meant to be better, and the argument
for FF3 is well founded for Ubuntu. I fully concede that. As for OOo,
I'm not AS convinced, but I will not argue against your statement.
However, NEW still does not unequivocally mean better.

LTS development: I do stand by my calls for a change in development.
An LTS, more than other releases, should stand for stability and
reliability, and should be developed accordingly.
Some ideas:

---Using a previous release as a "beta" for an LTS: Instead of syncing
packages with debian-sid on an LTS, use the packages from the LTS-1
release to find bugs and security holes. That way, when someone gets
the LTS, they know it's been through the wringer. This would be much
better than telling everyone they're getting an LTS when they should
really wait for the first point release to get patches.

---Having an extra long dev cycle: Give LTS releases more time, like
Dapper, instead of pushing them out on the same pace of a normal
release. Make the beta time longer to get kinks out, for example. This
would allow newer packages than the previous suggestion, while still
allowing more time to find errors.