2010/6/18 Ian Walls <ian.walls@bywatersolutions.com>

Had a thought randomly in the night about this thread, so I thought I'd resurrect it briefly.

There had been some discussion about whether to base releases on features or fixed time schedules, or a combination thereof. I think a combination is probably the best, and would suggest the following:

X.Y releases (like 3.2 or 3.4) being released on a features basis. That is, when a sufficient number of the RFCs for the release are met, the Release Manager says its time to publish the new version. Hopefully this will happen on a fairly regular basis, but we all know how development can go...

X.Y.Z releases (like 3.2.1 or 3.2.2) being released on a fixed schedule. These updates include all the new features and bug fixes that the Quality Assurance Manager and Release Maintainer agree are stable and solid. There will be as many of these updates as there is time for before the next major release. I'm completely open to the periodicity of these releases.

As Chris points out, this is only possible if bug fixes and features can be isolated from one another for integration into the timed releases. Developers publishing early and often will help with this, as well as maintaining Git repos with separate branches for various developments. The new git.koha-community.org site has the potential to allow various development groups to push code to their own branches in a safe and secure way, so that may be one way for teams working on longer-term projects to more easily integrate separate features. I believe this could also improve collaboration across development teams.

Does this sound reasonable to folks? Am I missing any major points of consideration?

Cheers,

-Ian

On Wed, Jun 2, 2010 at 7:38 PM, Reed Wade <reed@catalyst.net.nz> wrote:

On Thu, Jun 3, 2010 at 3:07 AM, LAURENT Henri-Damien
<laurenthdl@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

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

--
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth # 817
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls@bywatersolutions.com
Twitter: @sekjal

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel