• Koha
    The Open Source Library System
  • Drupal
    Content Management System
  • Piwik
    OPAC and web statistics
  • Services
    A complete range of services

Reply to comment

BibLibre, developpments rebase and you!

This post is about:

  • 2012 goals development rebases
  • Vision and roadmap
  • Progress and learnt of january and february
  • Why the community needs you

1/ One of BibLibre's aims for 2012

I'm currently at the head of the development department at BibLibre. Rebasing into community version the developments paid by our customers during 2011 is one of our strong goals for this year. This is the first reason to this message: letting you know about our work and our vision about this. BibLibre made 3 (financially unbacked) half-time available to this purpose. Those two and a half day per week for each developer can be used to submit, signoff and qa patches. Paul explained the context and strategy in this blog entry.

2/Rebasing strategy and projected roadmap

The list of 2011 and 2012 developments is publicly available in a google document.
This document still evolves, I think I have reached a pretty exhaustive list but it probably still deserves refinements (developments from 2010 especially). The information in this document doesn’t indicate anything about the complexity of a development. One line in this table could mean 10 lines of code just as it could mean 500.

We are driven by priorities and demand. One of the biggest demands touches to developments for acquisitions and serials modules (more than half of the developments listed for 2011) commissioned by the UJM Saint-Etienne univeristy library. François presented them during KohaCon 2011 and you can find his presentation.
We started in January and February with this priority. The babelthèque integration in Koha is also pretty high on our priority list since one of the libraries concerned with this project is moving to a community version pretty soon.
A lot of time has also been invested in integrating Solr to Koha, it doesn’t show on this document, but i can assure you that it is a pretty big piece as well, both for it’s technical aspects and its integration into the community version. I woul love to start this project with other people who don’t work for BibLibre during the 2012 Hackfest in Marseille which will take place in March from the 19th to the 23rd.
Then we will take care of other developments depending on BibLibre’s imperatives and other missions. The goal is that by the end of 2012, all the developments commisionned by our customers (or invested in by the company) will have been proposed to the community and tracked in the most intelligent possible way. (e.g. proposing everything right now would not be very helpful has patches would need to be reworked on constantly for the following months.)

3/ Progression on the first two month of 2012

I try to build tools that allow to track our progression, and give you as much visibilty as possible. Those tools will surely be improved while they're used.
One of them is a progression graph (which I call in my own words a "burndown chart")
The two main points I'd like to follow are:

  • the number of submitted patches
  • the number of validated and integrated patches

In practical terms, the graph already show that the number of patches we submit is greater than the number of the ones really integrated. Our submission rate is sufficient to achieve our goal, but validation and integration does not depend on us.

4/ The community needs you!

Validation and integration in community version needs an other actor than BibLibre!
Community integration can be divided in 3 main phases (reference):

  • 1/ Patchs submission, corrections if there are feedbacks - technical BibLibre team
  • 2/ Patchs signoff (functional validation) - everybody
  • 3/ Quality assurance (technical validation called "QA") - QA team elected by community

After 2 and 3 are passed, there is no more obstruction for patch integration (release manager has to merge patches into master version).

Phases 1 to 3 can’t be made by the same actor (BibLibre can’t do proposal, functional validation and technical validation) to extend to others points of vue and test cases. I reach to the second post reason: you can obviously be a part of the actors involved in the integration to community version process.

We make efforts to minimise technical obstacles you could meet. For exemple, Paul opened sandboxes to test and sign off patches without writting a command line.

We have a lot of work to do and I want you to become aware of the fact that BibLibre is not alone to be able to make things advance further !

Thanks to all who read this. I'll be delighted to answer your questions.

Reminder of documents to follow:

Reply

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.