Le mercredi 31 octobre 2012 à 10:59 -0700, Jesse Keating a écrit : > On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: > > * Jesse Keating, Jeremy Katz, and others who helped shape the current policy > > and theory of our release schedule felt that the 6 month release cycle > > was > > fine but that certain features were going to take longer to develop. > > Those would need to be developed and not enter into Fedora until they > > were > > close enough that they could be completed during that cycle. > > - No matter what we do to try and increase the development cycle within > > a release, there's always going to be issues that take longer than the > > release that we need to deal with. Perhaps, we just need to be better > > about making people follow this model. > > I'm not entirely sure what I felt then, but I'm certainly open to a > longer release cycle. In fact I'm very much in favor of one, one that > puts more time between "feature complete" and the actual alpha release. > All too often we see features crash land right at the deadline, and > any software that has to integrate across a lot of pieces (like > anaconda) gets stuck trying to account for all these changes in a very > limited time frame, only to be hindered quickly by a freeze process.
Or do like Debian and have more than 1 freeze. IE, the basesystem is freezed and then the rest is freezed. Having packages on the critical path to be frozen sooner could make sense. Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
