Strawman: Change the Ubuntu Release Cycle

[Evan]

>
> Given that the current
>
development cycle consists of 2 weeks planning, 15 weeks of feature
> updates & integration, 6 weeks of integration, and 3 weeks of final
> testing, it seems that any further reduction in the timeframes would
> likely lead to a somewhat unstable final product, and would not meet
> the "stable for everyday use except where 100% uptime is required"
> goal.
>

I wasn't aware of this development cycle, and was under the impression that
there was more testing going on than there actually is. Definitely scrap the
'more features less testing' bit.

My original worry in starting this thread was that the six-month cycle was
too short. I find that the normal releases aren't *quite* stable enough for
every-day use (even in a home environment) because of the features that are
only half-implemented and the "early-adopters penalty", while the LTS
quickly becomes too out-of-date for home users who prefer up-to-date
software.

We could try and make the normal releases more stable, but that would mean
either fewer new features per release, or a longer (maybe 8-month) cycle.
The longer cycle has some appeal, but I think that people using the non-LTS
release in expectation of up-to-the-minute software would start to get
impatient after that long. Another option is to try and keep the LTS more
up-to-date, and down-grade current releases to 'unsuitable for public use'.
This causes problems in large environments though, where frequent updates
can be a pain to roll out, and could break custom apps.

My suggested fix doesn't look all that great, but the original problem
remains. Home users want cutting-edge applications on a stable base.
Corporate users want to have everything as stable as possible. Right now we
have an LTS release that leaves everything as stable as possible, but the
normal releases are cutting-edge applications on a cutting-edge base.

I'm sorry if the above is a bit convoluted, but I was thinking my way
through the issue. Here is a greatly revised suggestion.

Divide Ubuntu (packages & development) into two sections:

   - The core (X, the Kernel, etc.)
      - Minor versions
      - are released with each normal release.
         - are developed in the current six-month cycle.
         - include only features that can be fully and properly
         implemented in a single six-month time frame.
      - Major versions
      - are released with each LTS.
         - are developed in a two-year cycle.
         - include all of the larger features that take longer than
         six months to implement.
      - The focus for core will always be on stability. If something
      can't be implemented properly for the next minor release, it is
dropped to
      the next major release instead.
   - The apps (Firefox, OpenOffice.org, etc.)
      - Rolling release cycle
      - Freeze for every LTS on last stable version

It's fairly complicated, but it seems to satisfy most of the requirements:

   - large corporate environments get a stable, constant release every
   two years.
   - home users get up-to-date applications on a stable base.
   - those who need a very stable base but up-to-date apps can install
   the LTS but then switch to the rolling apps repository.
   - developers aren't rushing to cram a complex feature into six months.

It doesn't solve the lack of service-pack disks. but with a larger focus on
core stability, hopefully fewer show-stopper bugs will make it into releases
anyways. It's almost definitely got it's own problems, but it should be an
improvement over our current cycle.

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20071231/485a93c5/attachment.html>