-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2010 04:26 AM, Stephen Gallagher wrote: > 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. There is a third option. When you are working on something that will span many releases and you don't want it to show up in the next Branched release, simply make a git branch yourself from master and work on it there. When we branch for the release, we branch from master, so if you haven't merged your long term work over to master it won't show up in the branched repo. (of course, you'll have to manually do a build one the repo has branched to prevent the "rawhide" build in koji from being "latest" in the branched repo). I totally understand how this could be confusing, and I wish I had a white board. But basically SCM branches are much cheaper and easier with git, so that you can collaborate and work on a long term feature on an SCM branch without disrupting master and without that work winding up on the release branch. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjb74ACgkQ4v2HLvE71NVV3QCeOOTzgv6O0UcIKGTH0SU1cmu+ MCAAoKJsOc+lbMa2RiEv8SX82wbCh3bj =rVXM -----END PGP SIGNATURE----- _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board