<div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Given that the current </blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> 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. </blockquote></div> 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:<ul><li>The core (X, the Kernel, etc.) </li><ul><li>Minor versions </li><ul><li>are released with each normal release.</li><li>are developed in the current six-month cycle.</li><li>include only features that can be fully and properly implemented in a single six-month time frame. </li></ul><li>Major versions </li><ul><li>are released with each LTS.</li><li>are developed in a two-year cycle.</li><li>include all of the larger features that take longer than six months to implement.</li></ul><li>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. </li></ul><li>The apps (Firefox, OpenOffice.org, etc.)</li><ul><li>Rolling release cycle</li><li>Freeze for every LTS on last stable version</li></ul></ul>It's fairly complicated, but it seems to satisfy most of the requirements: <ul><li>large corporate environments get a stable, constant release every two years.</li><li>home users get up-to-date applications on a stable base.</li><li>those who need a very stable base but up-to-date apps can install the LTS but then switch to the rolling apps repository. </li><li>developers aren't rushing to cram a complex feature into six months. </li></ul>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