RFC: Git workflow

Jason Guiditta jguiditt at redhat.com
Wed Feb 15 20:44:34 UTC 2012


On 15/02/12 15:34 -0500, 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 should add something here that I thought of after I sent the email.
Since each repo has a different version that is the 'current' for
-maint, I see that as extra headache when developing.  IOW, I could
need to pull the latest from 0.3-maint for aeolus-image, 0.4-maint for
aeolus-cli, 0.9-maint for conductor and ?-maint for configure.  Given
that you generally want to be on the 'equivalent' branch for the whole
set of repos, the chance of being on the wrong one for a given task
seems pretty high to me (as well as harder to script in our dev tools,
as mentioned on recent planning thread).

-j



More information about the aeolus-devel mailing list