On Wed, 2012-10-31 at 08:15 -0700, Toshio Kuratomi wrote: > On Wed, Oct 31, 2012 at 01:25:36PM +0100, Marcela Mašláňová wrote: > > The non existing contingency plan was wrong thing to do and it must > > be taken more seriously for features since F-19. > > > One way to deal with non-esitent contingency plans would be that they must > be feature complete and testable before merging. (instead of at Alpha). > There would need to be additional policy about when they needed to be > merged. I could see, for instance, that they'd have to be merged when > rawhide branched as that is the time when development of the new release > starts and allows people to rapidly say, ready: everyone else adjust your > code or not-ready: pull that change out and recognize how that's going to > hobble changes to anything else for the cycle. We could push as in, features are no longer targeted for a given release (as in the wiki page does not mention the Fedora release in which this feature will appear). They are developed on their way (allowing long time planning) and when ready merge into rawhide right after the branching, this would be when a feature is tagged for the release. Benefits, feature can be tested in rawhide right after the branching, more time to discuss the feature as they are not proposed for a given release but in a generic way and hopefully enough time between it is merged into rawhide and the branching for the next release to be able to revert the feature if desired. Pierre -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
