> > If we don't have the manpower right now then perhaps we should consider > extending the beta or release candidate stage by a week in order to give > the manpower we have enough time to solve the most significant problems? >
Once again, I'm no developer, but I'm quite confident a week wouldn't nearly be enough. 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. > I 100% agree. I like the concept of a six-month release cycle, but if it > means shipping with bugs of this visibility and magnitude then there is > something wrong. If we are going to ship with bugs like this, then we cannot > in all honesty call it a stable release. Maybe calling the 6-month releases > 'major development milestones' would be more appropriate, and leave the > 'stable release' moniker for LTS releases only. I think on a certain level, this is what Mark Shuttleworth is trying to do by trying to sync release cycles with upstream projects. 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. This should hopefully significantly increase the quality of the software in each LTS release. 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. Maybe that's something for a downstream project to do anyway. Perhaps Dell's updated Ubuntu version that they bundle on their netbooks. Alex
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
