<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 11:58 AM, Brendan Gallagher <span dir="ltr"><<a href="mailto:info@bywatersolutions.com" target="_blank">info@bywatersolutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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?</div>
</div></div></blockquote></div><div class="gmail_extra"><br></div>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:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* Keep each patch small.  Smaller patches are also easier to rebase.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* 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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* Make sure that the commit message expresses the idea that the patch is trying to achieve.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* 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):</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">patch 1: doom, doom has taken us all! (a summary of the problem, how the patch series will fix it, and the test plan)</div><div class="gmail_extra">patch 2: but wait, here's a plan for happiness (automated test cases for changes to a core routine)</div>
<div class="gmail_extra">patch 3: Achievement unlocked: happiness! (patch that fixes the core routine and the callers of it)</div><div class="gmail_extra">patch 4: Make our happiness visible (patch that does user-visible template changes)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* 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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* 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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* 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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><div>Regards,</div><div><br>Galen</div>-- <br><div dir="ltr"><div>Galen Charlton</div><div>Manager of Implementation</div><div>Equinox Software, Inc. / The Open Source Experts</div>
<div>email:  <a href="mailto:gmc@esilibrary.com" target="_blank">gmc@esilibrary.com</a></div><div>direct: +1 770-709-5581</div><div>cell:   +1 404-984-4366</div><div>skype:  gmcharlt</div><div>web:    <a href="http://www.esilibrary.com/" target="_blank">http://www.esilibrary.com/</a></div>
<div>Supporting Koha and Evergreen: <a href="http://koha-community.org" target="_blank">http://koha-community.org</a> & <a href="http://evergreen-ils.org" target="_blank">http://evergreen-ils.org</a></div></div>
</div></div>