Hi,

On Mon, Dec 9, 2013 at 11:58 AM, Brendan Gallagher <info@bywatersolutions.com> wrote:
Yes rebasing is frustrating and sucks a lot of time.  I don't know the answers.  But I would like to ask.  What can we do better to get our patches accepted faster?  (Is it really just sending Cait and Galen cookies everyday?)...  There has got to be somethings that those devs who maybe aren't feeling the same frustration can lets us all know?

As a general response to the specific question, which applies to all levels of the patch review process: one thing that helps is making one's patches easy to read.  How?  There's no magic formula, but several things that improve readability include:

* Keep each patch small.  Smaller patches are also easier to rebase.

* Keep each patch focused -- ideally, each patch does one thing, and one thing only.  By "one thing" I mean that it expresses one idea and that every part of that patch supports that idea.  For example, a patch may add a new parameter to a routine and update each use of that routine, but it shouldn't *also* clean up an unrelated routine.

* Make sure that the commit message expresses the idea that the patch is trying to achieve.

* If you need to write several patches to implement a feature, try to make the patch series as a whole tell a story.  For example (and this is *just* an example):

patch 1: doom, doom has taken us all! (a summary of the problem, how the patch series will fix it, and the test plan)
patch 2: but wait, here's a plan for happiness (automated test cases for changes to a core routine)
patch 3: Achievement unlocked: happiness! (patch that fixes the core routine and the callers of it)
patch 4: Make our happiness visible (patch that does user-visible template changes)

* If at all possible, organize a patch series so that it is conceivable that a subset of the series can be pushed to master -- that would be one way of dealing with controversial parts of the series.

* For a patch that goes through a lot of iterations of review: don't be afraid to squash them so that they tell a consistent story.  Be sure to retain attribution if you squash, of course.

* Don't get overly attached to your development branch or particular patches -- what ultimately matters is the master branch and the maintenance branches.  Making sure that master is reasonably readable and definitely stable takes precedence.

Regards,

Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org