[Mifos-developer] Open Release Process

[Keith Woodlock]

Hi All,

During the weekly dev meeting, Ed spoke about putting effort in to
making the 'processes' within the community as open and transparent as
possible. The process I want to bring up is the 'release process'.

As a developer, when I fix a bug in a release (say 2.2.1) I would like
the capability to be able to do a new 'point' release of that software
(so 2.2.2). I dont think we should have to wait for some imaginery
date in the future. We should be able to allow the user community to
benefit from our investment as soon as possible.

Timeline for doing bugs typically falls into 1-3 day timeframe and so
are very doable by 'open source volunteers'.

The other type of work we do is typically add new 'features' or
functionality. 'features' in mifos fall into two categories:

1) Features that are requested by 'user community' and succifient
knowledge and detail is known for developer to go and do the work.

2) More Specualtive features: developers dont have much detail but
know broadly that customers are looking for a certain type of
functionality (Android Client, Offline fall into this at present)

Timeline for this work is typically along the lines of weeks and months.

For a release that is not a 'bug' release, I would expect us to be
able to say that for release 2.3:

- We have some concrete pieces of work we want to deliver on this
release. (Even if we can only think of one item thats fine.. thats all
that gets into release, if theres nothing but ongoing 'dev', then
theres no release until something comes from the ongoing 'dev' work
thats needed)
- This is the minimum we have to get done for release to be finished
- All other 'dev' work by people in the community is 'outside' of
the next release boundary and so should be done in a 'dev' branch (i.e
not in the release branch)

- I have doubts about the need to say Release 2.3 will happen on a
praticular date/quarter. The release is done when the items are done.
For bug release we can and should release again, next day if possible,
If a feature takes a week, great. lets release, if it takes 13 weeks,
no problem, release when its done then.
- I have doubts about the merit of a 'code freeze' stage. Coding on
a release branch should stop when 'devs' believe they have completed
their work. All other coding on the project can continue as was; if it
was something not related to the 'release' it should of being going on
in a 'dev branch'. I guess this term of 'code freeze' has come to mean
something like this.

Just some thoughts that might help make us more responsive as
suppliers of software to MFIs.

The thing that blocks me from releasing a new release of mifos tomorrow is:

1) I dont know the steps involved in making it a 'release' or whats
needed to 'upload' it to mifos.org. Can someone help in making this
more transparent?
2) I dont think there is an open and transparent community process
in place for 'release planning'

regards,
Keith.

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Mifos-developer mailing list
mifos-d...@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer

[Udai Gupta]

+1

http://mifosforge.jira.com/wiki/display/MIFOS/How+to+release+software

[Ed Cable]

Keith,

Here are some more links from the wiki on the checklist team goes through before each release.

Testing/QA - http://mifosforge.jira.com/wiki/display/MIFOS/Mifos+Release+Test+Checklist

Release Plan - Checklist of tasks to complete before shipping each release - http://mifosforge.jira.com/wiki/display/MIFOS/Mifos+2.2.1+Release+Plan

Regarding the tactics of updating the page on mifos.org - I can post how that's done.  Essentially once the download is available on sourceforge - it's updating a couple links and one or two pages on mifos.org. 

Beyond the process of the release, I think the biggest question/concern is managing what goes into release.  Could we call a meeting of a sub-group to discuss this? I would like for Kay to join to pass on her knowledge.

Perhaps we can have this meeting on Friday or Monday.

Ed 

[Ryan Whitney]

Ed,

I think its worth going through the checklist, but we'll probably have to adjust.  Moving to a complete open source model would seem to change some of those plans, as part of the check list was for our org that had difference objectives.  

As Keith mentioned about code freeze, we did that for testing purposes, but do we really have a testing team anymore? Jakub, I think you have testers, are you planning to take over that?  I'm also wondering how other open source projects handle their testing.  And if we don't do much, then we'll have to strongly underline with mifos users they need to help us test heavily before rolling to production.

Anyways, just stuff to sort out.  

r

http://p.sf.net/sfu/rsa-sfdev2dev1Mifos-developer mailing list

mifos-d...@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer

---------------------------------------

Ryan Whitney

ry...@greenlikeme.org

US mobile: +1.206.734.5110

global: +1.206.235.4479

"Your work is to discover your work and then with all your heart to give yourself to it. " - Buddha

[Ed Cable]

All great points Ryan - should go straight on the agenda for that release planning sub-group call.

I was just pointing as background to existing release processes that we had documented on mifos.org.

I would hope that out of the meeting we can identify a slimmer release process and a means of choosing release manager (permanent or rotating).

Ed

[Emily Tucker]

The one thing I might add to this is updating mifos.org so it talks about
the right release and points to the right download.

Ed has the details on what work needs to be done and can provide the
necessary info. Hopefully it's trivial...

Very exciting!
Emily

> -----Original Message-----
> From: Udai Gupta [mailto:mail...@gmail.com]
> Sent: Thursday, November 03, 2011 5:08 AM
> To: Mifos software development
> Subject: Re: [Mifos-developer] Open Release Process
>
> +1
>
> http://mifosforge.jira.com/wiki/display/MIFOS/How+to+release+software
>
> ----------------------------------------------------------------------

[George Iberia]

we have a test plan and after freezing providing 3 tyoe of tests: functionality , performance and compatibility ... but very soon we will change it , we will not have qa at all and try to implement  self test approach. patches are very useful especially for users who wants to get fixes and do not care about qa.

[Jakub Sławiński]

Hi,

just a couple of my thoughts on this topic. You can download a fully
functional war/installation package from our hudson server after every
successful commit. This should be enough for the users who wants the
bleeding-edge versions of the application. Moreover, probably we should
also create some scripts to publish links to daily snapshots on our
mifos.org page (along with some announcements via twitter for example).
Now, if you commit some very exciting feature, you can always send an
email to our mailing lists to encourage people to try it.

Regarding the more official releases (with a full QA cycle), we will
provide such service to the community, but we will not be able to manage
more than 1-2 releases per month.

Regards,
Jakub.

[Ed Cable]

Hello all,

I wanted to follow up on trying to schedule a time for this meeting to discuss release management.  Let's think of it as the kickoff for the  Release Team. I've created the Release Team page on the wiki: http://mifosforge.jira.com/wiki/display/RES/Release+Team

For the meeting time I was thinking 830am PST/430pm GMT on either Monday or Thursday.

How do these meeting times sound? I will send invitations out to those already in the discussion on the list.  Anybody who would like to be a part of the Release Team and this call, please respond to this thread.

Ed

2011/11/4 Jakub Sławiński <jslaw...@soldevelo.com>

[Udai Gupta]

I am attaching a technical discussion mail which should have had
happen on mailing list where we talked about branching and release. I
thought it might be relevant, Keith you might already have original in
your mail box.