[Geoserver-devel] Discussing a switch to a time boxed release model

Forwarding the mail I’ve erroneously sent to geoserver-users instead of geoserver-devel

Cheers
Andrea

---------- Forwarded message ----------
From: Andrea Aime <andrea.aime@anonymised.com>
Date: Tue, May 1, 2012 at 4:34 PM
Subject: Discussing a switch to a time boxed release model
To: Geotools-Devel list <geotools-devel@lists.sourceforge.net>, GeoServer Mailing List List <geoserver-users@lists.sourceforge.net>

Hi all,
there is a set of recent event that makes me wonder if we would be better off
switching from the current “ad hoc” release system to a time released model
with more frequent releases.

The events that I’m thinking about are:

  • Jody back in December was ready to release GeoTools. But other people
    were not of the same advise and were actually surprised about release
    talks in the first place
  • me and Ben were ready to start the betas in late January, but others
    were not
  • in May with a beta out and we are still talking through GSIPs

Many “big” projects (linux distros, Gnome and so on) are using a timed
released model, so I’m wondering if we can try a similar approach with
GeoServer.

Just for the sake of discussion I’ve tried to lay out a GeoServer relase plan
based on a time boxed approach, here it is:

Inline image 4

Main points in the above proposed cycle:

  • monthly releases
  • six months release cycle
  • the stable series (yellow-is area) is mostly geared towards bug fixing and new plugins,
    with some agreement in the PSC we can also also backport new stuff
    that requires altering the published API
  • the green area is free development for whatever you want, with of course the
    requirement that the software keeps on building fine
  • the red area is hardening, which starts when beta1 is released and disallows
    new features and new API focusing on bug fixing
  • a new trunk is cut as soon as we enter harderning, that is, the day we release beta2
  • we get six months in which can still do pretty much whatever we want (well, sorta,
    I would expect no revolutions once beta1 is out)

The downsides that need to be tamed:

  • we have three months with 3 active branches
  • the process is release happy

About the 3 active branches, what we could do is maybe to cut the new trunk
one month later (at beta2), and my observation is that backporting stuff with
git “cherry-pick” is normally less painful, so if we also switch fully to git that
should be less of a pain.

About being relase happy, we need to make the gt/gs synched up releases
a snap, something that can be done in 2-4 hours tops, and something that
more people can do.

I believe the current approach, in which we take a well known revision that
already passed the full builds and the CITE tests on the build server, already
cuts down lots of the pain.
One more thing we could do could be to have a manually started build
on the server that automates further the release process, some parametric
Hudson/Jenkins build that taken a revision number creates the tag, switches
the revision numbers, commits the changes and builds the new binaries
making them available in some location that allows a download of them
(one for geotools, one for geoserver), so that the release technician
can download and double check, and then another one that automates
the uploading to sourceforge (assuming the hudson server has
plenty of bandwidth).

This would allow the release technician to focus on the other mundane
tasks:

  • manual testing the geotools builds (actually this one too could be
    automated, just build against an empty repo)
  • manual testing geoserver, building installers for various platforms
  • releasing on jira, preparing the announcements, blogs

The above too should be something that more people can do (e.g.,
some colleague of mine at GeoSolutions that does not normally
participate in active development), which means we would have to give
admin access to jira to more people

This way, when “release day” comes nobody is surprised, the
release can be cut in a rather quick time, and we can share the releases
load with more people.

Well… this is it. Opinions?

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf