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

3.14 EOL and 3.22 Release Maintainer
by Fridolin SOMERS 02 Sep '15

02 Sep '15

Hie there, I think time has come to declare the end of maintaining the 3.14.x. I'll provide a last version in octobre, so if you want something in it, feel free to contact me. It whas a really good exepience for me, I'd like to candidate as Release Maintainer for 3.22. Best regards. -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 0

Re: [Koha-devel] Thoughts about timing and Koha schedules
by Kathryn Tyree 01 Sep '15

01 Sep '15

Hi Brendan and all, I'll note the Catalyst perspective/experience on this. The financial year/deadlines in NZ are also July-June or Jan-Dec. The only time of year that is 'typically' quieter for us as a company is Mid Dec-Mid Jan while many of our customer libraries are closed. We take holidays, and catch up on upgrades for any libraries who like to test while their office is quiet. We wouldn't expect to be able to commit any more time to community efforts by changing the release dates. At present we have three people with community roles/monthly responsibilities, and everyone puts time into testing/patching when other work is quiet no matter what the time of year. If something urgent like security vulnerabilities are found, everyone who is needed in the patching effort drops everything else until those are fixed. It feels a bit like trying to find a time of day when everyone can come to a community meeting - it'll never happen! Therefore I think the most important thing is that the dates are fixed. I'd agree its something to put to the main list/everyone. Cheers, Kathryn Kathryn Tyree http://catalyst.net.nz/ Message: Date: Fri, 21 Aug 2015 01:56:45 -0700 From: Brendan Gallagher <info(a)bywatersolutions.com> To: Koha Devel <koha-devel(a)lists.koha-community.org> Subject: [Koha-devel] Thoughts about timing and Koha schedules Message-ID: <CANGWTFRMD2Jp2_Lqsr4bf=G0Rs6ywA7WjWNqUO2tJBiMkvZycA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi All - ByWater is on its 7th year, so we have a solid set of data for analyzing, and recently I've noticed a few things. Let me try and paint the picture. Major Koha releases are every six months and usually the 22nd day of the month, with the target being November and May. (Please correct me if I am wrong) Library funding cycles in the US run either fiscal year (July to June), Calendar year (January to December), or some odd fiscal year close to the July~June year. Ok that being said from the time management situation with ByWater that introduces a few complexities. (Let me describe the workflow and maybe you'll see what I am talking about) Most of the time a library will sign a migration contract with us that dictates we must have them "go-live" before a certain fiscal date OR the library isn't really able to "sign" a contract for services until a certain fiscally motivated date (which places us into a similar roll-out). That being said we find that May and November (plus and minus a month) are our busiest times of the year. I've got 3 people on the road for education/training, 3 people heavily in the fields of migrations scripts, and 3 developers that are heavily in the field of meeting development expectations for lots and lots of go-lives (*note - plus additional staff to support an influx in tickets or other support needs during a go-live period). So if we slide the releases to say February and August - I would be able to dedicate more man power (9+ people from the above paragraph) around the heavy testing/ debugging / bug writing/squashing periods for a release. I know I know - there isn't really a time that Koha doesn't need more testing, but I've noticed that the volunteer effort is usually much greater/demanding the closer we are to major release date. I am wondering if others are finding the same with their work schedules (other support providers, academic institutions, public institutions, and my favorite volunteers). Are there certain times of the years where your day job is predictably busy that you aren't able to dedicate the resources that you want towards the greatest project in the world Koha. With the data set that we're sitting on here, we are constantly seeking ways that we can contribute more. Just a thought and was curious if others analyzed a similar aspect with their environment and perhaps maybe we should bring such a discussion into the open or a general IRC meeting. Especially any of us that are support providers we should be always be thinking about how we can do more for Koha. Thanks and Cheers (another sleepless night thinking about my favorite subject - Koha), Brendan

1 0

Test Planck
by Tajoli Zeno 01 Sep '15

01 Sep '15

Hi to all, one important thing to do is to test in master the new code for plack. But, after install planck, how could I test error connect with plack ? Do you have any suggesstion about this topic ? Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli(a)cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

2 1

Facilitate integration of some patches
by Jonathan Druart 01 Sep '15

01 Sep '15

Hello devs, I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low. Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem. So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step. I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea. Cheers, Jonathan PS: If I am correct, we already have discussed about that previously.

9 10