Hello koha-devel, 2 weeks ago I posted a mail about the release schedule, saying: March, 23th (1 month before the release) = feature freeze. April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0 The "feature freeze" was explained a little bit more on the wiki page: * No major enhancements will be included after this date for this release. By "major" I mean an enhancement that has many string change(s) and/or database change and/or introduce major changes in the core of Koha, with an important risk of side-effect. * other enhancements can still make their way into 3.8 * bugfixes can still make their way into 3.8 I couldn't push all what was passed QA on friday, so I pushed some patches today, without taking care of the feature freeze, that I declare for the end of today. Some have aked me what I would consider as a "major ENH", and what I would consider as a "not major enh" ? (that still can be pushed this or next week)? I've reviewed all the patches that are in "need signoff" or "signed off" status, and could find only 2 that fit the definition of "major ENH" * Bug 7710 - multiple holds per title * Bug 7818 - support DOM mode for Zebra indexing of bibliographic records Those bugs 1-are large 2-are related to the core of Koha 3- could have side effect So they will wait for 3.10. All other patches can still continue their way for Koha 3.8 For the following bugs i'll be double checking, because there is a risk of side effect that is not negligible, and I hesitated to put them in the previous list: * Bug 7420 - Add max fines to circulation matrix * Bug 7641 - Add ability to suspend reserves * Bug 7736 - Edifact QUOTE and ORDER functionality (the side effect of this one is negligible, but the patch is huge !) But if they have a strong signoff (or, better, 2) before the "strong feature freeze", I'll push them. Comment on some other bugs: Bug 7759 - Use Koha-Contrib-Tamil to update Zebra data in background => would be an alternative, not a replacement, so could push it. Also, as a conclusion: as the perltidy process has not reached a consensus -which I sincerely thought it had !- I won't do anything about it. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi, On Mar 26, 2012, at 11:17 AM, Paul Poulain wrote:
* Bug 7818 - support DOM mode for Zebra indexing of bibliographic records Those bugs 1-are large 2-are related to the core of Koha 3- could have side effect So they will wait for 3.10.
I'd like to request that you reconsider this decision -- DOM filter indexing, while it does indeed represent a major enhancement, would not be a mandatory enhancement, since users would continue to be able to use the GRS-1 filter if they wish. By design, the initial set of DOM rules for MARC21 closely match the records.abs definition. In conjunction with the Solr work that BibLibre and others are undertaking, I'd like to toss another idea out -- of starting the process of deprecating GRS-1 use in 3.10. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@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
Looking over the patches on the Equinox branch, it does seem that while this is a significant feature in terms of it's meaning and utility, it has very little impact on the existing code, and will sit benignly in the corner until it is called upon. One of the XSLTs for DOM authorities is moved so it can be used by both biblios and authorities... we'd need to confirm that DOM authority indexing still behaves itself on both upgraded and new installations. Other than that, we're pretty safe to include these files, even if they're still being tested and developed (and what part of Koha isn't?) Users can make the choice to opt-in, or leave things as the default and experience no change. If we can confirm the above mentioned tests and get signoff on it before the beginning of April (such a quick signoff could be seen as community interest), I'd say this is safe for inclusion in 3.8, even if we need to mark it as still 'in beta' until 3.10. Of course it's your call, Paul, but that's my opinion on the matter. -Ian On Mon, Mar 26, 2012 at 12:06, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Mar 26, 2012, at 11:17 AM, Paul Poulain wrote:
* Bug 7818 - support DOM mode for Zebra indexing of bibliographic records Those bugs 1-are large 2-are related to the core of Koha 3- could have side effect So they will wait for 3.10.
I'd like to request that you reconsider this decision -- DOM filter indexing, while it does indeed represent a major enhancement, would not be a mandatory enhancement, since users would continue to be able to use the GRS-1 filter if they wish. By design, the initial set of DOM rules for MARC21 closely match the records.abs definition.
In conjunction with the Solr work that BibLibre and others are undertaking, I'd like to toss another idea out -- of starting the process of deprecating GRS-1 use in 3.10.
Regards,
Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
Ian, A brief note in response to your concern: One of the XSLTs for DOM authorities is moved so it can be used by both
biblios and authorities... we'd need to confirm that DOM authority indexing still behaves itself on both upgraded and new installations. Other than that, we're pretty safe to include these files, even if they're still being tested and developed (and what part of Koha isn't?) Users can make the choice to opt-in, or leave things as the default and experience no change.
The XSLT in question, koha-indexdefs-to-zebra.xsl is not actually used by Zebra in the day-to-day business of indexing. It's used by developers who are revising their DOM index definitions themselves. As far as I know, Galen and I are the only two people who have modified the authorities DOM configuration, and therefore the only two people who have actually used that conversion script, most likely. As an aside, Galen and I briefly discussed the wisdom of storing the generated authority-zebra-indexdefs.xsl in the git repository, but concluded that there was no reason to add a dependency on xsltproc, given that the file rarely needs to be regenerated. In conjunction with the Solr work that BibLibre and others are undertaking,
I'd like to toss another idea out -- of starting the process of deprecating GRS-1 use in 3.10.
Woohoo! +1 from me! Pursuant to that goal, Bug 7421 (by Frédéric Demians) implements DOM indexing for UNIMARC authorities ( http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421 ). Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
On 3/27/12 1:43 PM, Jared Camins-Esakov wrote:
The XSLT in question, koha-indexdefs-to-zebra.xsl is not actually used by Zebra in the day-to-day business of indexing. It's used by developers who are revising their DOM index definitions themselves. As far as I know, Galen and I are the only two people who have modified the authorities DOM configuration, and therefore the only two people who have actually used that conversion script, most likely. As an aside, Galen and I briefly discussed the wisdom of storing the generated authority-zebra-indexdefs.xsl in the git repository, but concluded that there was no reason to add a dependency on xsltproc, given that the file rarely needs to be regenerated.
I just wanted to mention that we also use a modified DOM authorities configuration. We're a couple of versions behind, so it would be hard for me to test anything in timely manner this time around, but Jared's absolutely correct that moving koha-indexdefs-to-zebra.xsl should have no effect on day-to-day functionality. Brian -- Brian Harrington Content Development Coordinator Project MUSE The Johns Hopkins University Press brian@jhu.edu
participants (5)
-
Brian Harrington -
Galen Charlton -
Ian Walls -
Jared Camins-Esakov -
Paul Poulain