dist-git proof of concept phase 2 ready for testing

[Jonathan Underwood]

2009/12/21 Jesse Keating <jkeating at redhat.com>:
> 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.

Something that would be really nice on top of this would be allowing
*any* contributor to create and push private/topic branches while only
allowing contributors allowed by the ACL to push to the branches from
which builds occur.

Use case: I see a problem with a package. I fix it and push to a topic
branch, and then contact the package owners and ask them to merge it.
Faster workflow than going through bugzilla.

 This might all be one pony too far at this stage though, and might be
phase 10 wishlist stuff.

J