[Koha-devel] ping Koha (developers) community

[Galen Charlton]

Hi,

On Mon, Dec 9, 2013 at 11:58 AM, Brendan Gallagher <
info at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131209/4d8f1469/attachment-0001.html>