Hi All,

While drafting the board report I realized we are delaying our releases by a 
long time. Our last release was in early january. We are slowly moving from 2 
months to 3 to 4 months. As soon as 0.7 release is done, can we please consider 
my proposal below and follow a strict 6 week cycle. Any delay, lets properly 
justify and take exception. Since i did not see any objections before, I will 
call upon a vote.

+ 1 I agree 6 week release discipline will be good
+ 0 I do not have an opinion on this topic
-1 I do not agree because …..

Cheers,
Suresh

On Jan 22, 2013, at 9:47 AM, Suresh Marru <[email protected]> wrote:

> Hi All,
> 
> As the RM for the first 5 release I have set a bad example on the release 
> process which I would like to request all of us to consider fixing it. We 
> have a very reasonable high commit activity but we are lagging behind on 
> releases and feeling little disorganized. On a good side we are using JIRA 
> efficiently to capture all issues but we are not using them effectively to 
> plan releases (thanks Ate for the wake up call). 
> 
> How about we take our agile philosophy [1] literally ? Here is a plan I 
> propose for the releases:
> 
> * Follow a strict 6-week release cycle? We can take exceptions but they have 
> to be well justified. 
> 
> * 2 weeks JIRA-a-Thon: identify the release features: 
> ** To focus on quality then quantity, focus on only one or two major features 
> (created as epics or stories) 
> ** call out for a virtual  to get all get all tasks related to the next 
> release into jira (or tag existing ones to to the release version)
> ** this the time for the community to respond and make specific requests if 
> they have a burning feature they would like to see in the next release 
> ** free new feature jira tagging to the next release
> ** advertise the next release notes (there may be more bug fixes added later) 
> 
> * 2 weeks Hack-a-Thon: Run through all the development (added to the 2 weeks 
> of parallel development which happens during JIRA-a-Thon)
> ** address any deferred issues from previous release
> ** bug fixes coming through from previous releases 
> ** feature/bug fix freeze 
> ** defer any un-finished issues to next release
> 
> *1 week Test-a-Thon: Integrations and testing on trunk and 1 RC
> ** The RC testing among other random testings will need to ensure all 
> advertised release features/bug fixes are properly tested
> ** improve documentation along with creating release specific documentation
> 
> * 1 week Release-a-Thon: Fix RC issues, and iterating over and making a 
> release (if all goes well) 
> 
> Spin the cycle 
> 
> applauses, grievances, yellings, welcome !! 
> 
> Cheers,
> Suresh
> 
> [1] - http://airavata.apache.org/development/roadmap.html
> 
> 

Reply via email to