- Koha-devel - lists.koha-community.org

FW: [Koha] Commentary on Paul's Koha 3.8 Release Manager proposal
by Marcel de Rooy 08 Sep '11

08 Sep '11

I think both proposals (from Paul and Ian) contain very good points, are ambitious and motivating for the community. With people like Ian and Paul in the release team, we will definitely reach a Koha 4.0! I would however not favor working in parallel on Koha 3.8 and 4.0 as well as maintaining 3.6.X (and possible even 3.4.X for a while). I think that three or four versions together with lowering quality standards will not result in a better product, but could imply more bugs, rebasing problems and time lost on synchronizing between versions, testing in multiple versions, etc. Why not keep it simpler? Develop in master (heading to 4.0 and solR), and keep 3.6.X stable (as soon as 3.6.X is there, declare 3.4.X end-of-life too). Just focus on those two versions. A long feature list for 4.0 is very nice and Ian's development plan may theoretically be the best way to go, but probably hard to realize in practice. A simpler approach would be: as soon as solR and searching is ready and stable, we reach 4.0. This could be after 3.8, 3.10, .. (Stick to the 6m cycle.) We have been growing into a higher QA standard when we came from 3.2. I think it would be a pity if we already lower that standard too quickly. A problem is obviously the longer time between submission and pushing. Probably, we could improve in that area by adding some persons at the QA level (Ian may have two assistants in 3.8?), asking the bug wranglers to test older patches first and let them communicate more about these patches, and doing QA first on these older signed patches. Currently, time does not really rule selection of a patch in signoff or QA, but other factors like author, size, attractive title, etc. At the same time we could allow people perhaps to sign the more easy, trivial patches themselves (especially if they have them running in production already somewhere). If QA would disagree, they could lower the patch status back to Needs signoff for getting another external test. We could make a proposal how to change current procedures for this without compromizing quality. What we should avoid, is large, very large patches without test plan. These patches did not come through now too. Which is quite understandable. Such patches should be broken up into manageable units with a test plan. Hope this helps, Marcel > Everyone, > > > Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release > Manager. The details of his document can be found here: > http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38 > > I thoroughly agree that the time has come to start thinking beyond the > next stable release, and on to Koha 4.0. Those of you who have seen > either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know > I'm very excited about the possibilities of where we can take Koha in > it's next major iteration. However, I disagree with a couple of the > details of Paul's proposal. > > The major disagreement is with the timeline. The proposal as it stands > is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8 > releasing April 2012, and Koha 4.0 releasing Oct. 2012. I feel that > going from Koha 3.8 directly to 4.0 is unwarranted. To my mind, there > are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 > and so forth. This is supported by the actual database version numbers > in Koha: the current release is actually 3.04.04; the zeros are squashed > out for convenience. > > I would counter that, while we should continue releasing new features > every 6 months on the 3.X line, Koha 4.0 should be defined by it's > features. Paul's proposal calls several features to be key, including > Solr integration, database abstraction, updated online help, improved > authentication stack and automated tests. I agree that all these things > are important and should be worked towards, but I'm not convinced they > should be the sum total of the changes that define Koha 4.0 > > I would like to see the following in Koha 4.0: > > * arbitrary metadata formats (beyond MARC) > * arbitrary biblio relationships > * full support for authority records, including uploading through > the GUI, automatic linking, "explode" searching and more > * improvements to the borrower data structure (fewer pre-defined > data fields, more flexibility) > * separation of "receiving" and "payment" in acquisitions > * serials import and export (MFHD, prediction patterns, etc) > * many, many more things > > I think that the community should meet and discuss what features are > both desirable and reasonably likely to be completed in the next few > years (is there interest by libraries to sponsor these developments, or > from developers to code it "for fun"?). > > Once a feature set is agreed on to "define" Koha 4.0, the developers of > these features would meet to hash out what underlying structural changes > would be required to make them happen. Hopefully commonalities could be > found, so that the underlying structure could be developed in a way that > accommodates multiple developments at once. Identifying these > prerequisite changes early on would reduce the difficulties of rebasing > developments, since we'd all be working off a similar set of base > assumptions. It would also provide a reasonable basis for excluding or > delaying developments that don't fit into the overall plan. > > Once the features were chosen and a framework for their development > agreed upon, it would be time to code. The development and submission > process would be the same as it is now (basing patches off master and > submitting to the patches listserv and Bugzilla). As new features > become ready, they would be incorporated into the time-based 3.X > releases by the release manager for that particular cycle. This way, > what works is made available, and what needs more time continues to be > tested until it's stable for production use. Once all the agreed upon > features were ready, it would be time to release Koha 4.0. Hopefully, > that would be with 1-2 years, but there would be flexibility here. > > One of my other issues with the proposal was the "lightening" of Quality > Assurance standards for the first 3 months of the 3.8 release cycle. If > operating under the 1 year time frame for Koha 4.0 as outlined in Paul's > proposal, this would seem necessary in order to get everything included > in time. Unfortunately, while the next 3 months would be dedicated to > clean up of features rolled in, there is never any guarantee of bug > fixes being generated in a timely fashion. You cannot force people to > write or sign off on bug fixes; we're all free agents here. So code > that has not been rigourously tested could get in and stay in for a long > time, long after 4.0 would release, because no one knows how to test it > or fix it. > > However, if we operate under my proposed model, all code could continue > to operate under the same quality assurance standards, and nothing that > is broken or otherwise incomplete would make it in until it was ready. > Releases would still come out every 6 months, even if a major > development was inoperable, until that development could be completed. > > This has been a long email, so let me sum up. I think: > > * we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month > cycles using the current community practices for feature inclusion > * we should, as a community, meet and decide what features we want > to define Koha 4.0 > * the developers of those features should get together and come up > with a unified plan for accomplishing them all, in a way that > requires minimal rebasing > * as new features become stable and tested, they should be folded > into the 3.X line until all the features defined as "Koha 4.0" are > ready > * Once all the agreed upon features are complete, Koha 4.0 is then > released. > > I've already gotten some feedback on this in today's Koha IRC meeting, > but I'd very much like to hear what the rest of the community thinks > about this, particular in relation to Paul's proposal for 3.8 Release > Manager. Our time is limited for discussion, as the election time draws > near, but hopefully I've made my thoughts clear enough for a dialogue to > get started. Please let me know if I've been at all unclear. > > Cheers, > > > -Ian > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > Phone # (888) 900-8944 <tel:%28888%29%20900-8944> > http://bywatersolutions.com > ian.walls(a)bywatersolutions.com <mailto:ian.walls@bywatersolutions.com> > Twitter: @sekjal > > > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

Roles for Koha 3.8
by Paul Poulain 07 Sep '11

07 Sep '11

Hello, A reminder: Everyone that plan to volunteer for a position in next Koha 3.8 version is welcomed to file his/her name on the wiki page: http://wiki.koha-community.org/wiki/Roles_for_3.8 The following positions are (desperately) empty: * Translation Manager * Documentation Manager * Documentation of DB * QA Manager * Specific Module maintainers * Release Maintainer * Packaging Manager 2nd reminder: on july IRC meeting, we decided: 1. /AGREED/: Express interest via the mailing list for Nominations by 22 September. Elections in October (see http://librarypolice.com/koha-meetings/2011/koha.2011-08-02-02.00.html ) so, you still have 21 days left... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 2

Fwd: [Zebralist] Zebra 2.0.49 available
by Ian Walls 06 Sep '11

06 Sep '11

Everyone, Just an update. Apparently "scan" was broken. -Ian ---------- Forwarded message ---------- From: Adam Dickmeiss <adam(a)indexdata.dk> Date: Fri, Sep 2, 2011 at 8:41 AM Subject: [Zebralist] Zebra 2.0.49 available To: Zebra Information Server <zebralist(a)lists.indexdata.dk> Zebra 2.0.49 is available. Packaged for Debian, Ubuntu , CentOS and Windows 32-bit. This version includes fixes for scan. ______________________________**_________________ Zebralist mailing list Zebralist(a)lists.indexdata.dk http://lists.indexdata.dk/cgi-**bin/mailman/listinfo/zebralist<http://lists.indexdata.dk/cgi-bin/mailman/listinfo/zebralist> -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

3 3

Meeting Times
by Elliott Davis 06 Sep '11

06 Sep '11

Hi All, I just wanted to remind everyone about the IRC meeting tomorrow September the 7th at 18:00 UTC. Also please note this is a nominations meeting. For those that are interested we will also be having a meeting September the 8th at 18:00 UTC to discuss revamping the notifications system. Please refer to the wiki for proposed details http://wiki.koha-community.org/wiki/Notifications_RFC Best Regards, Elliott Davis Robert R. Muntz Library University of Texas at Tyler

1 0

Koha db schema pecularities
by Jared Camins-Esakov 06 Sep '11

06 Sep '11

Hello. I was looking at the schema that Koha uses for its database, and noticed a few peculiarities that I wonder if anyone could shed some light on: The serial table uses VARCHAR(100) for serial.biblionumber and serial.subscriptionid. Is there any context in which those are not numeric identifiers? Presumably as a result of that, there are no foreign key constraints on the serial table. I think there probably should be. There's a similar situation with the subscription table: subscription.biblionumber doesn't have a foreign key relation with biblio.biblionumber, nor, indeed, any index at all. Foreign keys are also lacking for subscription.aqbooksellerid and subscription.aqbudgetid. On the subject of foreign keys, should items.itype have a foreign key linking it to itemtypes? My understanding of foreign key relationships is that they're a Good Thing because they provide a means to ensure referential integrity. Am I missing something in these particular cases (and there are probably others, these are just the ones I happened to notice), or would people say this was probably just an oversight? Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

2 1

koha 4.0 / solR / Zebra : A working group is born ?
by Paul Poulain 03 Sep '11

03 Sep '11

Hi, As you all know, BibLibre has worked hard on integrating solR as search engine into Koha. The resulting work is live in 2 french libraries, and we plan to integrate it into Koha 4.0 Our preference went to do a in-depth work. It mean we changed the API a lot, as well as most of the logic behind the search in Koha. It means we can't keep zebra working as it is today. Fortunately, the proposed structure is modularized, so it's possible to re-implement zebra for those who want to stay with it. It's also possible to reintegrate NoZebra or any other search engine. Zeno Tajoli sent us a mail with some starting work about this re-implementation of zebra. I catched tcohen on IRC today, his boss gave him some time to investigate too. Claire Hernandez (our development manager) is also helping. Unless i'm mistaking, it's a draft of a "search engine working group". If anyone else is interested, drop me (or claire) a mail, we could organize an IRC session. PS: i've submitted a presentation for KohaCon11 about what we did around solR. But it will be librarian-oriented. We will/could/should probably have a topic about that during HackFest as well ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

9 10

Idea for patch header (1st line)
by Paul Poulain 02 Sep '11

02 Sep '11

Hello all, I'm following through RSS what is pushed, and I would be interested in having a specific marker for patches that are related to Enhancements. Something like Bug XXXX blabla => it's a bugfix Enh XXXX blabla => it's an enhancement I try to track pushed enhancements, I think doc writters & translators would be highly interested by this difference as well. Your opinion ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 2

jquery plugin
by Paul Poulain 02 Sep '11

02 Sep '11

Hello koha-devel, On the bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6086 Alex proposes to add a new jquery filter for tables, picnet.table.filter.min.js (An example of the filter is here: http://www.picnet.com.au/resources/tablefilter/demo.htm ) We already have some jquery plugins for table: * tablesorter = let you sort table columns. Widely used in Koha. * tablesorterPager = automatically paginate long tables. Used in admin section of Koha, and in readingrec * uiTableFilter = add a generic filter to tables. Used only in serials claims if i'm not mistaking. uiTableFilter and tablefilter achieve almost the same goal: * uiTableFilter propose just one filter, generic, outside of the table. You enter something, and any cell with the entered value is kept, others are hidden * tablefilter add a line to the table, just below column names (see the screenshot on bug 6086) the filter can be very detailled. It handles filters from a list, not only from an entered value. We have options: * those 2 plugins are not exactly the same, let's go with both (at the price of sometimes graphic inconsistencies or difficulties to choose one or the other plugin) * uiTableFilter is great, the other gives us too much detail, let's stick with uiTableFilter, don't add another table plugin ! * tablefilter is great, it's better to have a lot of details, it's easier to understand how it works (the uiTableFilter is outside the table, it's strange...) switch to tablefilter and remote uiTableFilter ! What do you think we should do ? Is there an other thing we should take care of ? Anyone knowing the killing-plugin-for-table we should use for sorting/filtering/doing everything on table ? Personally, I think I prefer a little bit tablefilter, I already had some usability questions from Owen about uiTableFilter used in a smart-rules patch we've submitted (and has not been applied yet) Depending on the conclusion, i'll QA the 6086 differently ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

6 7

Strange encoding problems that sometimes happens
by Paul Poulain 02 Sep '11

02 Sep '11

Hello, English natives will less concerned by this problem probably, but there are/were some places where strange encoding problems occurs. We have a fix for them (use utf8 decode function), but I was wondering what was the origin of this problem. I think Frédérick Capovilla has a good explanation that I share with you (it's a copy/paste of but 6479) > It's been a while since I created that patch but here is what I understand : > > I remember that in the NewIssue subroutine of Serials.pm, The content of > $serialseq is concatenated with a variable fetched from a SQL query and that's > where the problem happen. > > I did some tests to check the utf-8 flag on those two variables > $serialseq = variable from the form (is_utf8 = false) > $recievedlist = variable from SQL (is_utf8 = true) > > The encoding of the data fetched from SQL differs from the encoding of the data > received from the form. If two string with a different encoding gets > concatenated together, the encoding of one of the string is automatically > changed, and we get an encoding problem on one half of the string. > > Using decode on $serialseq adds the utf-8 flag, so we don't get an encoding > problem when we concatenate. > > > We don't get this encoding problem when the first item is added in > $recievedlist because $recievedlist is empty and doesn't automatically get the > utf-8 flag. I'm guessing Perl DBI automatically addes the utf-8 flag if it > finds utf-8 characters in a string returned from a SELECT. If there are remaining places where this problem occurs, we know why & how to fix it then ! PS: This explanation sounds highly logical to me. But if someone disagree or has another explanation, feel free to drop a comment on the bug or continue this thread ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

call for help = BZ6328
by Paul Poulain 02 Sep '11

02 Sep '11

Hello all, Koha 3.6 will be released in less than two months, and there is a very important patch that I just rebased a few minuts ago (& squashed) It's the BZ 6328, and is related to fine in days. For french libraries it's a must-have, 99% of french libraries set fines in days of debarment instead of money. This feature had been integrated in 3.4, but it was not functionnal, some important things were missing (it works on biblibre/master, the problem was, as many times we've already seen, we had everything in a single branch). So i'd like to see this patch taken into account. So if you want to have a look (yes, you...), feel free ! Thanks -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0