[openspending-dev] Roadmaps and release schedules

[Tryggvi Björgvinsson]

Hi all,

I'm moving this bit of news from Nigel into a new thread because I'm
diverging from it:

> After a few days of effort, I finally have OpenSpending staging setup at
> staging.openspending.org.

First of all, great news Nigel! Awesome. It's good to have a staging
server. Thanks a bunch.

Now let's try and put this staging server to good use.

I propose we try to agree on some sort of a release schedule with fixed
deployments to the staging server and then to the official server. What
I have in mind is that we decide on how and when we do releases of the
code, basically decide on release dates (versions?).

So to start the discussion I'm going to suggest we try and set up a 6
month release schedule (which everybody has probably grown tired of if
they follow Ubuntu development or Gnome development or all of the other
processes). That is, I propose we do two new releases of the
OpenSpending platform per year (changes to the master branch of
OpenSpending - rebase and tag). What dates? I have no particular dates
in mind but we can say one in the summer and one in the winter. January
15th and July 15th releases perhaps? All suggestions welcome.

Websites (or software for that matter) are not perfect so we need to be
able to push hot fixes in the form of a partly-rolling releases. We
should have a specific branch to collect these in (hotfixes?) and merge
them into master when we are absolutely sure that they fix the problem
and don't break anything else. We can also just keep them in their own
branches in forked repos on github or gitorious. Doesn't really matter.
I think keeping them in a central repo helps others find them and it can
give us a good overview of what is going into the code base as hot fixes.

After each release we start working on the next release in a development
branch and try to work towards a common goal, follow a roadmap we all
agree on. The roadmap doesn't have to fully implemented before we do the
release and the roadmap isn't the only thing we can work on. There are
ever-changing requirements we need to deal with and for open source
software anybody can contribute anything at any time (which we will then
look at and see if we merge it). This means we should look at the
roadmap as guideline not an absolute. It just tells us where we wanted
to go with the when we agreed on the roadmap but the roads may change.

After a period of hacking on roadmap stuff and hacking on other stuff we
like we should make a feature freeze. Here's where the staging server
comes in. We put the code as it is up on the staging server and start
testing it, iron out any bugs and the translation teams can jump in and
do their work and use the staging server as a reference. If we want to
show stuff which we've been working on we could use pagekite
(pagekite.net) to serve our own staging servers (or when we're not using
the staging server we can use that as well).

On the release date we merge the code into master, deploy, write a blog
post and then go have a good time (grab a lot of beers or have tea or
whatever we want to do to feel proud of ourselves). Shortly thereafter
we start work on the next roadmap, agree on it and then we're off again.

So the 6 month schedule would be something like this:

Month 1: Agree on roadmap for the next few months / Hack on things we like
Month 2: Hack on roadmap / Hack on other things we like
Month 3: Hack on roadmap / Hack on other things we like
Month 4: Hack on roadmap / Hack on other things we like
Month 5: Hack on roadmap / Hack on other things we like - End of month =
feature freeze
Month 6: Iron out bugs, translations - End of month = release and party!

This will spark off some other decisions we need to make as a community
and I'll try to formulate them over the next days in separate emails
(this email is long enough already).

What do you think? Is this something we would like to do? I'm all up for
it. Any other suggestions welcome as well as arguments against.

/Tryggvi