dist-git proof of concept phase 2 ready for testing

[Jesse Keating]

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.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20091220/c9f4330c/attachment.sig>