-----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 <[email protected]> > 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 <[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 >>> >>> >> >> > -----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-----
