On Wed, 2010-09-29 at 07:26 -0400, Stephen Gallagher wrote: > > 2) We need a new policy regarding branching. Currently, the new and > > upcoming version of Fedora is branched from Rawhide at the moment that > > development begins on it. This needs to change. > > > > Instead of branching from Rawhide, I think Fedora N+1 should be branched > > from Fedora N. Rawhide should remain an exciting think-tank of > > in-development features, but we should always plan for Fedora N+1 to be > > a more stable environment. In this way, it should be first of all easy > > for developers to upgrade their system into Fedora Branched. > > > > This is, I feel, the most important part of my proposal here. If nothing > else from this email is addressed, I think this needs to be. > > Rawhide CANNOT function as a rapid development environment if it is > regularly Branched. There are many projects that benefit from the > ability to use Rawhide for long periods of time to stabilize a new > feature before it belongs in a stable release. > > Currently, such contributors have only two options: > 1) Keep an eye out for when Rawhide is going to branch and unpush their > packages until after the branch is done, then re-create them. > 2) After the branch is done, bump the epoch on their package in the > Branch and revert it to a known good state (or pull it completely from > the Branch, if it's a new package) > > Both of these approaches are highly disruptive to a working development > environment. > > I think that it really only makes sense for development to branch from > the previous STABLE release (plus updates). It should be the > responsibility of package maintainers to manually move rawhide packages > into the Branch at that time. Then they can more easily decide when > development is truly ready for inclusion in a stable release. FWIW, +1. This would be awesome and very much overdue if it happened. Jon. _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
