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

Fri Jun 18 14:48:20 CEST 2010

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 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.
>
> -reed
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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 at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100618/0032b371/attachment.htm>