[openspending-dev] Roadmaps and release schedules

[Vitor Baptista]

Hey Tryggvi!

I feel the trend in the webdev world is to deploy as often as possible,
getting to extremes like GitHub (
https://github.com/blog/1241-deploying-at-github) doing dozens of deploys
per day. In 2012, they did 175 deploys in a single day!

I would love to see us moving towards that. As we are such a small group,
it shouldn't be that hard. The next steps, now that we have a staging site
(thanks, Nigel!), could be to work on our deployment process. Configure a
deployment tool (maybe Fabric?), configure Travis (or Jenkins), and set up
a way to deploy, automatically, every commit to our staging site, if the
tests pass.

After that, we just need a way to do the same for production. Not deploying
automatically, obviously, but making it as easy as possible. Ideally, one
button.

What do you think?

Cheers,
Vítor.

2013/3/8 Tryggvi Björgvinsson <tryggvi.bjorgvinsson at okfn.org>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20130308/4f75a3cd/attachment.html>