airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raminder Singh <raminderjsi...@gmail.com>
Subject Re: [VOTE] 6 week release cycle
Date Wed, 10 Apr 2013 15:43:51 GMT
+1 

On Apr 10, 2013, at 11:30 AM, Chathuri Wimalasena wrote:

> +1 for having 6 week release cycles.
> 
> Regards,
> Chathuri
> 
> 
> On Wed, Apr 10, 2013 at 11:08 AM, Amila Jayasekara
> <thejaka.amila@gmail.com>wrote:
> 
>> +1, please.
>> 
>> Regards,
>> Amila
>> 
>> 
>> On Wed, 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
View raw message