airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject [RESULT] [VOTE] 6 week release cycle
Date Tue, 16 Apr 2013 10:24:16 GMT
With 72+ hours, this vote is now closed with the following tally:

+1 Saminda Wijeratne*
+1 Marlon Pierce*
+1 Heshan Suriyaarachchi*
+1 Amila Jayasekara*
+1 Chathuri Wimalasena*
+1 Raminder Singh*
+1 Suresh Marru*

* Binding votes - Airavata PMC Member

The VOTE passes with 7 +1 binding votes and no negatives. The resolution is: Airavata will
follow a 6 week release cycle. I will update the website. 

Cheers,
Suresh
On Apr 10, 2013, at 8:13 AM, Suresh Marru <smarru@apache.org> wrote:

> 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 <smarru@apache.org> 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
>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message