RFC: Git workflow

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


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



More information about the aeolus-devel mailing list