Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

Pierre-Yves Chibon pingou at pingoured.fr
Wed Oct 31 15:25:50 UTC 2012


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


More information about the devel mailing list