RFC: Git workflow

Steve Linabery slinaber at redhat.com
Thu Feb 16 16:04:42 UTC 2012


On Wed, Feb 15, 2012 at 03:44:34PM -0500, Jason Guiditta wrote:
> 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

I favor the approach that is the least complex/confusing for the most people. I would rather concentrate the complexity/gymnastics on a few people managing branches than expect every developer to grok the issues around releases, maint branches, etc. every time they push a commit.

So I favor jayg's Option 1.

s|e



More information about the aeolus-devel mailing list