Re: [VOTE] 6 week release cycle

[Saminda Wijeratne <sa...@gmail.com>]

+1.

Quick release cycles is good to stabilize new features. Perhaps further we
can make 6 weeks the upper limit so that we can go for shorter release
cycles if needed.


On Wed, Apr 10, 2013 at 8:13 AM, Suresh Marru <sm...@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 <sm...@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
> >
> >
>
>

Re: [VOTE] 6 week release cycle

[Marlon Pierce <ma...@iu.edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1

On 4/10/13 9:33 AM, Saminda Wijeratne wrote:
> +1.
> 
> Quick release cycles is good to stabilize new features. Perhaps
> further we can make 6 weeks the upper limit so that we can go for
> shorter release cycles if needed.
> 
> 
> On Wed, Apr 10, 2013 at 8:13 AM, Suresh Marru <sm...@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 <sm...@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
>>> 
>>> 
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRZXlLAAoJEOEgD2XReDo54YsH/AqsAcya4FT4W8jBli09DWbb
MuYIJUZJ3qNBeTj8stUkqyqnU2Zf74S95F71V8ifKVLZ7OgYbsRXF/C0Rtnrf5iF
qaYuf+1wmK7N99bXjC3U/ZBBI5Zg/NPAaJ7sMwSELU0YD9PQ3XTpDx2yyiVZJPJW
liBMopn8xdZGN5rjUD8gRNCgI6SW7E6VRP+6RnWNPpZ79iIubPpotw9exkkVnLd5
nA4rmiMxsXBVf4cxhgdkUXmtHar+YIUmNM6rEwAIkq3qp/DAIO2QtC6MeJYXexKH
N2T13ikjmC/EvK+PHMUrAxNu92dYBOUATJpUFaSjLF8JoxxDXDRNRNT8hTIcc/I=
=NblN
-----END PGP SIGNATURE-----