On Thu, Nov 26, 2009 at 02:01:00PM +0000, Terry Barnaby wrote: > another set of problems. The new release speed also uses a lot of > developer and user time in just managing to create a new release and > updating systems to use it. This is the key flaw in your suggestion. Fedora developer effort isn't as malleable as you seem to think -- managing a new release is very different from fixing graphics bugs, and even if everyone involved in a different aspect of the project _wanted_ to switch to graphics driver programming _and_ was qualified to do so _and_ was able to get up to speed in a reasonable time, you can't necessarily solve programming problems faster by multiplying the number of developers. On the other hand, having a release which emphasizes stability over new features is an idea that's been around for a while. It may be a good idea occasionally, but one of the problems you get is that new development in general doesn't stop and wait for stabilization, so the _next_ release, where you open things up again, ends up extra-unstable as all that new stuff hits at once. -- Matthew Miller <mattdm@xxxxxxxxxx> Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
