<div dir="ltr">Hi,<div><br></div><div>Feature slush is imminent, as is feature freeze.  Here are some notes on what I expect this to mean in practice.</div><div><br></div><div>New Features</div><div>--------------------</div>
<div>At this point, every bug that is in a state of passed QA, with exceptions I will name below, can provisionally be considered candidates for inclusion in Koha 3.14.  Any new feature or enhancement patch that reaches passed QA by 23:59 on September 25, 2013 in my time zone (UTC-7) can likewise be provisional candidates.</div>
<div><br></div><div>By provisional candidate I mean the following:</div><div><br></div><div>[1] I will review it and either push it or give an opportunity for the submitter to address QA concerns.</div><div>[2] My presumption will be that the feature end up getting pushed to master.</div>
<div>[3] This NOT, however, a guarantee that it will get pushed -- my primary concern is a stable master; if we run out of time (by which I mean the end of hackfest at KohaCon) to address quality concerns on any given patch, it's not going in.</div>
<div><br></div><div>Any patches that reach passed QA between September 26, 2013 and 23:59 on October 3, 2013 will also be considered provisional candidates for release, but are more likely to be held over for post-3.14 if there are problems.  In other words, enhancements that reach slush will get looked at first.</div>
<div><br></div><div>Exceptions</div><div>----------------</div><div>I am giving the following enhancement bugs special dispensation to be considered for inclusion even if they miss the freeze date by a bit:</div><div><br>
</div><div>* 8798: Add the use of DBIx::Class</div><div>* 10565: Add a "Patron List" feature for storing and manipulating collections of patrons (depends on DBIx::Class)</div><div>* 10493: Add renewal script (depends on DBIx::Class)</div>
<div>* 10309: New OPAC theme based on Bootstrap <br></div><div>* Bugs related to adding DOM indexing support for UNIMARC</div><div>* Bugs related to LDAP</div><div>* Debian packaging improvements</div><div>* Bugs related to the GRS-1 deprecation announcements being discussed</div>
<div>* Bugs related to making QueryParser enabled by default, also being discussed</div><div><br></div><div>The following bugs currently in a passed QA state will get pushed in some form, but I will be submitting a counter-patch:</div>
<div><br></div><div>8190: Add a logging module to Koha<br></div><div><br></div><div>The following bugs currently in passed QA may not get pushed:</div><div><br></div><div>9854: Add 'ttf-dejavu*' packages to debian/control file, for label printing (bug 8375) -- the patch for this does not stand on its own until patches for related bugs are ready</div>
<div><br></div><div>7167: updatedatabase improvements -- I have spent a *lot* of time mulling this one over -- and in the final analysis, in my opinion it would add far too much complexity to solve a problem that can be addressed by our agreeing never to fail a patch purely on the basis of a resolvable merge conflict.  To my knowledge, that is current the case.</div>
<div><br></div><div>The current practice of linearly applied schema changes, while not the most flexible possible system, has been /very/ successful for the average Koha user, and I am very hesitant to risk regressions during upgrade.  </div>
<div><br></div><div>Organizations who deploy new developments in advance of their release -- and I appreciate why and how that happens -- ultimately must take responsibility for managing schema updates for their customers.</div>
<div><br></div><div>However, I do have thoughts on a possible compromise that can provide a /simple/ mechanism to specify that specific updates are to be bypassed.  I'll will think on this some more and update the bug by the end of the week.  But sneak preview -- if we make it possible for DBrevs to be identified by both the version number and a tag (such as the bug number, for example), it would be simple to set up a mechanism for somebody to inject DBrevs in advance of a release without having to know the version number that ultimately gets assigned, then have <a href="http://updatedatabase.pl">updatedatabase.pl</a> bypass reapplying those specific revisions -- without having any effect on a stock Koha database.  This wouldn't solve everything, if the schema and data changes for the update get modified during the patch review process, but that's part of the risk anybody assumes by running in advance of master.</div>
<div><br></div><div>Bugfixes</div><div>------------- </div><div>There is no specific freeze date for bugfixes except the constraints imposed by string freeze at the end of October.  However, I cannot guarantee that all bugfixes that reach passed QA before release will make it in; patches that stabilize new enhancements will take precedence during the month of October.</div>
<div><br></div><div>Regards,</div><div><br></div><div>Galen</div><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>