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

[Reed Wade]

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.

-reed