dist-git proof of concept phase 2 ready for testing
jkeating at redhat.com
Mon Dec 21 04:40:27 UTC 2009
On Mon, 2009-12-21 at 05:06 +0100, Kevin Kofler wrote:
> So what do you suggest doing in such a case? Temporarily reverting the F-n
> branch to the old release, build, then bump it up again? This sounds really
> suboptimal to me (in addition to being a regression from our current CVS
> setup, which does allow creating such branches)! Branching is really part of
> what VCSs are for.
You're right, branching is a real part, that's why you would start the
foo-1.1 work on a topic branch, and only merge it into origin/F-12 when
you're ready to build it and push it through bodhi. Just like you'd
work on a new feature on a feature branch and only bring it over to
origin/master when you're ready to merge it with everything else.
Treat the origin/F-?? as the master for that release, do your long
running not immediately ready for build work on topic branches thereof
and only merge them when you're ready to build. This reduces the
surprise should another developer need to quickly build out an update
that is unrelated to any major change you may have cooking.
Fedora -- Freedom² is a feature!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the fedora-devel-list