[openspending-dev] Roadmaps and release schedules

Fri Mar 8 17:12:48 UTC 2013

Hi,

I think this is a bad idea.

The idea of OpenSpending.org is to be the platform you go to if you want to know about budget and money flows. OpenSpending is Open Source software, but it's actually not meant to be set up by individual organisations (unlike e.g. CKAN), because having a central datastore for spending data allows for cross dataset analysis and better insight.
Of course we want the software to be stable and of course people can set up their own instances. But we really don't have the requirement to have a release cycle of 6 months.

OpenSpending is actually still at the very beginning, there are lots of ideas and there is lots of potential to grow. Pushing new features out only after 6 months limits our agility and publicly visible development speed significantly.

A staging server is actually a means that encourages agile and speedy development and deployment: you can deploy and test your brand new awesome code without having to worry to crash the production server and if everything works well, you can deploy. Current devops trends are not to deploy every 6 months (we are not SAP or IBM!), but to deploy every day.
We certainly don't have to deploy every day, but if I can't see my code improvements live within a week and instead have to defend the current deployment state to users, I have no motivation to improve our code.

Please let us not only think about what would be best for code stability, but also for keeping the pace of this project.

Cheers
Stefan

On 08.03.2013, at 16:31 , Tryggvi Björgvinsson <tryggvi.bjorgvinsson at okfn.org> wrote:

> 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
> 
> 
> 
> _______________________________________________
> openspending-dev mailing list
> openspending-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending-dev