[Koha-devel] BibLibre strategy for Koha 3.4 and next versions

Chris Cormack chris at bigballofwax.co.nz
Thu Jun 3 01:55:43 CEST 2010


On 3 June 2010 11:38, Reed Wade <reed at catalyst.net.nz> wrote:
> On Thu, Jun 3, 2010 at 3:07 AM, LAURENT Henri-Damien
> <laurenthdl at alinto.com> wrote:
>> Le 02/06/2010 12:22, Reed Wade a écrit :
>>> Any reason not to move to a 4 week release cycle? With alternate ones
>>> getting "better" testing.
>>>
>>> It would mean automating a lot of things -- but doable and worth it in any case.
>>
>> ^^The main reason is this one.
>> and no doubt that it IS BOTH doable AND worth.... But in what time and
>> who would do that... BibLibre is willing to devote time for that... But
>> this surely is a community effort with development and should be managed
>> as such.
>> maybe there should be teams along with the assignees of bugs which could
>> make smaller patches, and meetings so as to report progess.
>
>
>
> (4 weeks is probably too short but...)
>
> Yes, getting the science and organisation correct would be key.
>
> Something ChrisC has alluded to in emails and IRC is the scheme we
> have developed at Catalyst for a project he and I and (5-8 others)
> work on. It is a long running development effort for a high scale news
> web site. It has a similar architecture and larger code base than
> Koha. We use git and there's a lot of perl. It seems likely there are
> some bits of code and techniques that could be applied to Koha release
> mgmt.
>
> We have a 4 (really 1-6) week release cycle which is feature and date
> driven (customer might need new thing in time for national elections
> or sporting event and they don't tend to plan too far ahead).
>
> We use debian packages for all code deployments and DB updates.
>
> We use a system similar to bugzilla for tracking code development.
> Each feature or bug fix gets a branch named according to the ticket
> number.
>
> We have an automated process which merges all branches for the next
> release (it queries the issue tracker to know what tickets are in what
> release) and emails the authors if there's a conflict. This runs
> several times a day. Instructions embedded in the ticket comments are
> used to sort dependencies and additional / alternate branches if
> needed for conflict resolution.
>
> We have a similar automated process which performs the merge then
> creates debian packages for our testing environment. It emails the
> results to the release manage who reviews and sets the status of
> updated features so QA staff know what they can now test (this should
> be automated but isn't just yet because I like to review these still).
>
> We have a pre-production autobuild set up which is a duplicate of all
> that but it only takes branches that QA have signed off on (examines
> ticket status).
>
> This scheme has been extraordinarily satisfying and effective and
> allows us to spend more time on real work instead of the mechanics of
> the process. Production deployments used to be long bad days and now
> they tend to be uneventful. Everyone is happier. Release management is
> now time spent considering product features instead of the mechanics
> of integration and testing.
>
> The key benefits we've gained are:
>  - at any moment you can play with what would be the release if you
> decided to release at that moment
>  - developers become responsible for fixing code conflicts or other
> blocks to their branch getting into a release and without hardly any
> time needed by the release manager (so very low latency for fixes) to
> wrangle that because it's automated emails telling the developer
> something went wrong
>
> --
>
> How to apply to Koha?
>
> There are differences. We are a small group, mostly in the same
> office. Our customer is a 5 minute walk down the street from us.
>
> I was about to say that our trade-offs and priorities are clear -- but
> that wasn't true before we had the system described above. It's
> allowed us and the customer to focus on keeping things clear because
> they've seen the value of things like having a feature freeze date
> that doesn't change unless the release date changes.
>
> Some key things that could be taken--
>
>  - the auto-build and merge and report and package on a test machine
> for easy QA system
>  -- this is something we should be able to adapt to bugzilla and make
> available for the project
>
>  - the notion of naming branches according to bug/feature id -- we've
> found this to be very powerful
>
> Chris or Lars may have something to add.
>
I think the most important part of our system is indeed the separate
branches per feature/bug
This allows features to be removed and the release still happen, if
they fail testing.

Time based releases simply can not happen if we cant easily remove
failing code. (Or not merge it as the case may be).

Chris


More information about the Koha-devel mailing list