Hi, On Mon, Dec 9, 2013 at 11:58 AM, Brendan Gallagher < [email protected]> 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: [email protected] 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
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
