<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>If we don't have the manpower right now then perhaps we should consider<br>




extending the beta or release candidate stage by a week in order to give<br>
the manpower we have enough time to solve the most significant problems?<br></div></div></blockquote><div><br>Once again, I'm no developer, but I'm quite confident a week wouldn't nearly be enough.<br>
<br>Not only that, but I'm certain that the regressions listed in thie original mail isn't the only one that would be considered serious. Multiply it tenfold at least I'd say.<br><br>> I 100% agree. I like the concept of a six-month release cycle, but if it<br>


> means shipping with bugs of this visibility and magnitude then there is<br>
> something wrong. If we are going to ship with bugs like this, then we cannot<br>
> in all honesty call it a stable release. Maybe calling the 6-month releases<br>
> 'major development milestones' would be more appropriate, and leave the<br>
> 'stable release' moniker for LTS releases only.<br><br>I think on a certain level, this is what Mark Shuttleworth is trying to do by trying to sync release cycles with upstream projects.<br><br>Take the recent announcement by Debian that they will regularly freeze their stable releases on a regular cycle, and Ubuntu's efforts to sync their LTS relase with the Debian stable release.<br>

<br>This should hopefully significantly increase the quality of the software in each LTS release.<br><br>However, without a more stringent QA process, Ubuntu aren't making any guarantees to stop these types of regressions, not even in LTS releases. But that's OK, they're still doing absolutely incredible work.<br>

<br>Maybe that's something for a downstream project to do anyway. Perhaps Dell's updated Ubuntu version that they bundle on their netbooks.<br><br>Alex<br></div></div>