RFC: Git workflow

Greg Blomquist gblomqui at redhat.com
Thu Feb 16 15:19:50 UTC 2012


On 02/16/2012 05:18 AM, Tomas Sedovic wrote:
> 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.

Some random thoughts on this topic:

Tbh, I have all but halted any aeolus conductor work until the
"temporary release-related" stuff is sorted and conductor development is
following some suitably sane process for accepting patches.  I'm
currently sufficiently confused as to where patches should go and where
I should push those patches once accepted.

Being not directly on either conductor or infrastructure core
development teams, I have found it hard to keep up with the various
changes in development processes.

Further, I think this is going to be a recurring problem each release,
no?  It seems better to find a single comfortable development process
that has a lower potential for common mistakes (like selecting the wrong
branch for a patch) and that works when in and out of a release cycle.

Perhaps it's better to revisit the comments made (much?) earlier on list
about having many more frequent and smaller releases, that way the teams
are always in a release cycle and not, uh, cycling between release and
development.

---
 Greg



More information about the aeolus-devel mailing list