RFC: Git workflow

Tomas Sedovic tsedovic at redhat.com
Thu Feb 16 10:18:06 UTC 2012


On 02/15/2012 09:34 PM, Jason Guiditta wrote:
> Hello list, had a concern I wanted to raise about our git workflow and
> see if we could get a consensus before too much time went by.
> Apparently there was a recent decision that I somehow missed to do all
> our work on the newly minted *-maint branches, and then merge those
> into master periodically (with the plan for it to be fairly frequent).
> As soon as I became aware of this plan, I raised eck and eggs to ask
> them why the change, as I dont think this is the same as what we have
> been doing of late. I will outline below the 2 proposed workflows,
> listing what I thought we had agreed to a few months back, as well as
> the new one. If I am off on details, someone chime in and correct me,
> otherwise I'd like to see which one people think makes more sense
> before we get too commited to this change and feel stuck again.
>
> == Option 1 (the way we were doing it) ==
>
> 1. All development happens on master
> 2. If there is a bugfix for a previous release that would go into a
> maintenance release, that gets cherry-picked off master and put on
> the release branch.
> 3. At the end of a sprint or set of sprints, another 'major' release
> branch is created off of master with its own set of bugfix releases
>
> == Option 2 (what I think is proposed now) ==
>
> 1. Bugfixes are done directly on the *-maint branch, which is
> 'frequently' merged into master 2. New development/feature work is done
> on master
> 3. Same as 3 above
>
> So my concern here, aside from another change in workflow, is that in
> a given sprint you may work on one task that needs to be done against
> foo-maint, and then on the next task be working against master.
> Peronally Option 1 makes more sense to me, but I can roll with
> whatever the consensus is here, just wanted to get the question out
> before it was too late. Thoughts?
>
> -j

I assumed (maybe incorrectly) that this is a temporary release-related 
thing and we'd revert to the good ole master-based development later.

If that's not the case, I'm definitely in favour of developing on master 
-- provided eggs and eck can make that work.

It's less confusing for the newcomers and as you point out, the 
consistency results in lesser chance of someone picking up wrong 
branches for their work.



More information about the aeolus-devel mailing list