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

Bugs to sign off
by Chris Cormack 07 Apr '13

07 Apr '13

Now that bug 8770 has been signed off, there are no blockers left, however there is Bug 8252 which is marked critical. It is to do with UNIMARC searching, so if a UNIMARC user could test it that would be excellent. Then there are just 4 major 9986 9575 9414 5366 That will leave just 21 bugs to have their patches signed off, (maybe less depending on how my kids behave and if I can sign off some more today) Chris

2 1

Branching 3.12.x tomorrow
by Galen Charlton 05 Apr '13

05 Apr '13

Hi, Tomorrow I will be branching 3.12.x. Bugfixes required for the 3.12.0 release will be pushed to master first, then cherry-picked for 3.12.x. Jared and I will both be committing to the master branch until 3.12.0 is released, while Jared will be the sole person pushing to 3.12.x. As far as master is concerned, prior to the 3.12.0 release I will focus on pushing QA-ed bugfixes, but I may also push a few enhancements to master. I think it is very safe to assume that any enhancements pushed to master will not be cherry-picked to 3.12.x. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)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

2 3

Re: [Koha-devel] Koha numbering
by BWS Johnson 05 Apr '13

05 Apr '13

Salvete! You silly, silly man. Everyone knows that anything past nine isn't real maths. ;) xkcd.com/899/ I still mostly don't care how things are numbered. I care far more that thongs operate how they ought to. Cheers, Brooke

4 3

LTS support (branching the "Koha numbering" thread)
by Tomas Cohen Arazi 05 Apr '13

05 Apr '13

Maybe this could go into a different thread? I think is off-topic On Fri, Apr 5, 2013 at 10:32 AM, Paul <paul.a(a)aandc.org> wrote: > At 07:34 AM 4/5/2013 -0400, Kyle Hall wrote: > >> From what I've I've heard around the water cooler, we won't be switching >> to >> 4.x until there is some major change to the internal infrastructure of >> Koha >> ( like Solr support, or perhaps DBIx::Class support ). >> >> >> I think if were to ditch the traditional versioning system, that maybe the >> Ubuntu year/month style would. So a major release this month would be >> version 13.04. I'm not endorsing it, it's just a possibility ; ) >> > > I would very much like to see something along the "Ubuntu style" as > *production* is very different from development and product improvement > and/or security issues (which is great/marvelous, to be encouraged, the > life and soul of an open-source project, etc) > > Many (most?) production environments are based upon a two-year cycle with > security upgrades; this opinion based on the last twenty years of IT > proliferation out of my fifty years in IT. Enhancements come down to a > question of "is it really helpful in our environment?" and "what are the > risks/costs of modifying a working system?" (Some of us are more/less > blessed with a permanent sandbox capability and the time/resources to use > it beneficially for our commercial/charitable goals. But this should not be > relied upon.) > > A two year "LTS" cycle, with a further two years "support", plus one more > year of "not dropping off the edge of the world" works extremely well as a > policy principle, which I feel must be based upon a principle of "if it > ain't broke, don't fix it." (Ubuntu is slowly getting there - it's now > nearly trivial to limit apt-get upgrade to security issues only, and > consider product enhancements at a totally separate level. Could Koha do > the same with the "package" option? One of the reasons that I use tarballs > is the granularity of looking through the release notes for security > issues.) > I belive LTS could be a good thing for Koha. The main problem is that the effort needs to be done by someone. The current way of handling this ("version XX will be deprecated unless someone steps in as release maintainer") is a good approach in this scenario. If an institution (or group of them) is not ready for a major version jump, they should sponsor the maintenance of their current version. We plan to use 3.12 as soon as it gets stabilized until something really better arises. Version numbering *might* be related to LTS in the way we currentl name packages and things that need to be done to retain a certain version from a major upgrade. I'd go for the naming schema is used for virtualbox (for example): koha-common-3.10 koha-common-3.12 and so on. Regards To+

2 1

Re: [Koha-devel] Koha numbering
by Paul 05 Apr '13

05 Apr '13

At 07:34 AM 4/5/2013 -0400, Kyle Hall wrote: > From what I've I've heard around the water cooler, we won't be switching to >4.x until there is some major change to the internal infrastructure of Koha >( like Solr support, or perhaps DBIx::Class support ). > >I think if were to ditch the traditional versioning system, that maybe the >Ubuntu year/month style would. So a major release this month would be >version 13.04. I'm not endorsing it, it's just a possibility ; ) I would very much like to see something along the "Ubuntu style" as *production* is very different from development and product improvement and/or security issues (which is great/marvelous, to be encouraged, the life and soul of an open-source project, etc) Many (most?) production environments are based upon a two-year cycle with security upgrades; this opinion based on the last twenty years of IT proliferation out of my fifty years in IT. Enhancements come down to a question of "is it really helpful in our environment?" and "what are the risks/costs of modifying a working system?" (Some of us are more/less blessed with a permanent sandbox capability and the time/resources to use it beneficially for our commercial/charitable goals. But this should not be relied upon.) A two year "LTS" cycle, with a further two years "support", plus one more year of "not dropping off the edge of the world" works extremely well as a policy principle, which I feel must be based upon a principle of "if it ain't broke, don't fix it." (Ubuntu is slowly getting there - it's now nearly trivial to limit apt-get upgrade to security issues only, and consider product enhancements at a totally separate level. Could Koha do the same with the "package" option? One of the reasons that I use tarballs is the granularity of looking through the release notes for security issues.) My $0.2 and YMMV, Best regards and thanks for all the hard work, Paul

2 1

Re: [Koha-devel] Koha numbering
by Quoc Uy 05 Apr '13

05 Apr '13

Nice question. I don't know, too. But really, the 3. has important meaning, i guess! Maybe nicole engard or chris and answer! Best regards! Nguyen Quoc Uy On 05.04.2013, at 14:00, koha-devel-request(a)lists.koha-community.org wrote: > Send Koha-devel mailing list submissions to > koha-devel(a)lists.koha-community.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > or, via email, send a message with subject or body 'help' to > koha-devel-request(a)lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner(a)lists.koha-community.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha-devel digest..." > > > Today's Topics: > > 1. Koha numbering (Paul Poulain) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 05 Apr 2013 09:40:22 +0200 > From: Paul Poulain <paul.poulain(a)biblibre.com> > To: Koha Devel <Koha-devel(a)lists.koha-community.org> > Subject: [Koha-devel] Koha numbering > Message-ID: <515E7FE6.5030506(a)biblibre.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello koha-devel, > > Throwing the question : after version 3.10, we're about to release 3.12, > the next version is expected to be 3.14 > > My question is a small one : what does the "3." mean for us ? > The 3.12 is really different from 3.0, that has been released 5 years > ago. Remembering history, we switched from 1.x to 2.x when MARC support > was added. We switched from 2.x to 3.x when zebra became our search engine. > > What could/should we expect to decide to switch to 4.x ? > > Another option I see could be to remove the "3." and name version 12.0, > 12.1, 12.2, 14.0, 14.1,... (that would be fine for the current > updatedatabase mechanism) > > Thoughts ? > > -- > Paul POULAIN - BibLibre > http://www.biblibre.com > Free & Open Source Softwares for libraries > Koha, Drupal, Piwik, Jasper > > > > ------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)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/ > > End of Koha-devel Digest, Vol 89, Issue 6 > *****************************************

1 0

Re: [Koha-devel] Jesse Weaver will be working with ByWater for the Summer.
by BWS Johnson 05 Apr '13

05 Apr '13

Salvete! Won't matter. Everyone knows that Galen is a bot. *duck* Cheers, Brooke

1 0

Jesse Weaver (pianohacker) will be working with ByWater for the Summer. Special Request to join QAA team..
by Brendan Gallagher 05 Apr '13

05 Apr '13

Hello All - Jesse Weaver, the 54th committer to Koha, will be working with ByWater from May 15th to about August 15th of 2013. He will be dedicated to working only on Koha work, like signing off on patches and fixing bugs. I also had another thought that if we could get him accepted to the QAA team for those three months that would be a great help there also. We all know that he's got the skills and the ability. I am interested to hear if there are any objections to this. Jesse has stated that he would look forward to helping out with the QA load. Of course since he will be paid by ByWater - he will not QA or sign-off on ByWater patches/code. Either way we will be dedicating his time to Koha work. Thank you for your comments and thoughts and sorry to not bring this up in the last General IRC meeting - it was at 3am my time and I was still working on the details with Jesse for this summer. Perhaps this should be brought up and voted on during the next General IRC meeting? Or will this mailing and no objections suffice? Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions

6 5

BibLibre hires a student to work during summer for the community
by Paul Poulain 05 Apr '13

05 Apr '13

Hi koha-devel, I'm happy & proud to announce that a student, Kenza, will join the Koha community from june 4th, to august 31st. She will be 100% dedicated to community work : signing-off patches, playing with bugzilla,... I hope she will also be able to write unit tests. If someone has ideas for dev work that could be useful, feel free to suggest (I'm talking about omnibus/generic ideas, not "pls sign-off patch XXXX") Her english is good, she knows nothing about Perl & git (mySQL & web technologies are OK), but she'll learn quickly ;-) HTH ! PS: of course, it's northen summer. So southern winter ;-) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

4 3

Re: [Koha-devel] Jesse Weaver (pianohacker) will be working with ByWater for the Summer. Special Request to join QAA team..
by BWS Johnson 05 Apr '13

05 Apr '13

Salvete! That's great news if you ask this non dev. :) Cheers, Brooke

1 0