[Koha-devel] 3.14 feature freeze notes

Galen Charlton gmc at esilibrary.com
Tue Sep 24 23:35:00 CEST 2013


Hi,

Feature slush is imminent, as is feature freeze.  Here are some notes on
what I expect this to mean in practice.

New Features
--------------------
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.

By provisional candidate I mean the following:

[1] I will review it and either push it or give an opportunity for the
submitter to address QA concerns.
[2] My presumption will be that the feature end up getting pushed to master.
[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.

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.

Exceptions
----------------
I am giving the following enhancement bugs special dispensation to be
considered for inclusion even if they miss the freeze date by a bit:

* 8798: Add the use of DBIx::Class
* 10565: Add a "Patron List" feature for storing and manipulating
collections of patrons (depends on DBIx::Class)
* 10493: Add renewal script (depends on DBIx::Class)
* 10309: New OPAC theme based on Bootstrap
* Bugs related to adding DOM indexing support for UNIMARC
* Bugs related to LDAP
* Debian packaging improvements
* Bugs related to the GRS-1 deprecation announcements being discussed
* Bugs related to making QueryParser enabled by default, also being
discussed

The following bugs currently in a passed QA state will get pushed in some
form, but I will be submitting a counter-patch:

8190: Add a logging module to Koha

The following bugs currently in passed QA may not get pushed:

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

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.

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.

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.

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 updatedatabase.pl 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.

Bugfixes
-------------
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.

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/20130924/0960dd9e/attachment-0001.html>


More information about the Koha-devel mailing list