Re: How can we support a faster release cadence?

2014-02-11 Thread Thiago H de Paula Figueiredo
On Tue, 11 Feb 2014 03:51:25 -0200, Marvin Humphrey wrote: On Mon, Feb 10, 2014 at 3:57 PM, Dave Fisher wrote: I have a real example where defined cadence is not as good as the Apache Way. Apache policy does not forbid releasing on a predictable schedule. Projects are already free to

Re: How can we support a faster release cadence?

2014-02-11 Thread Jim Jagielski
On Feb 11, 2014, at 12:51 AM, Marvin Humphrey wrote: > On Mon, Feb 10, 2014 at 3:57 PM, Dave Fisher wrote: >> I have a real example where defined cadence is not as good as the Apache Way. > > Apache policy does not forbid releasing on a predictable schedule. Projects > are already free to rel

Re: How can we support a faster release cadence?

2014-02-11 Thread Joseph Schaefer
+1. Thinking early releases will yield higher quality confuses cause and effect. The organization Jim describes is the organization I joined over a decade ago, and still think the values he expresses are worth hanging onto today. On Feb 11, 2014, at 9:37 AM, Jim Jagielski wrote: > > On Feb 11

Re: How can we support a faster release cadence?

2014-02-11 Thread Stephen Connolly
It concerns me that people are knocking a fast release cadence *without having tried it here* Q: Is a fast cadence right for every project at ASF? A: I think not Q: Is a fast cadence right for the majority of projects at ASF? A: I suspect not Q: Is a fast cadence wrong for any project at ASF?

Re: How can we support a faster release cadence?

2014-02-11 Thread Joseph Schaefer
The core question for me is do we want to continue down this path of attempting to be all things to all people with no common culture or values or processes, or is there a floor somewhere. If there is, where should it be? I don’t expect you to answer that question but that’s what’s bothering me a

Re: How can we support a faster release cadence?

2014-02-11 Thread Jim Jagielski
On Feb 11, 2014, at 10:37 AM, Stephen Connolly wrote: > It concerns me that people are knocking a fast release cadence *without > having tried it here* > No one is knocking a fast release cycle proper. People are knocking those who push a fast release cycle w/o considering why some basic core

Re: How can we support a faster release cadence?

2014-02-11 Thread Shane Curcuru
On 2/9/14 2:03 PM, Doug Cutting wrote: On Sat, Feb 8, 2014 at 2:44 PM, Henri Yandell wrote: * Go and fork the project code on GitHub. * Put your changes in there and PR them up into the Apache codebase. * If others want to, they can PR the code to you, and then you can PR the code up to the cod

Re: How can we support a faster release cadence?

2014-02-11 Thread Benson Margulies
Could I suggest a focus on making the release process easier? That will benefit everybody, and serve as a platform for ongoing discussion about releases and cadences. It seems to me that we could make voters' jobs easier. This would help get releases approved _in 72 hours_, to start with. We ask

Re: How can we support a faster release cadence?

2014-02-11 Thread Andy Seaborne
On 10/02/14 12:50, Stephen Connolly wrote: Well first off, my experience is that users are reluctant to even test -alpha- and -beta- releases and consequently there is next to zero chance of them testing an RC. Additionally with fast cadence releases the RC will most likely get released anyway..

Re: How can we support a faster release cadence?

2014-02-11 Thread sebb
On 11 February 2014 17:01, Benson Margulies wrote: > Could I suggest a focus on making the release process easier? That > will benefit everybody, and serve as a platform for ongoing discussion > about releases and cadences. > > It seems to me that we could make voters' jobs easier. This would help

Re: How can we support a faster release cadence?

2014-02-11 Thread Andrea Pescetti
Jim Jagielski wrote: One reason for the 72hour rule is to ensure that no PMC member feels disenfranchised. ... PMCs are *inclusive*. The processes and procedures are designed to maintain that inclusivity. This is not 100% incompatible with 12-hour votes. Our current rules assume that the PMC a

Re: How can we support a faster release cadence?

2014-02-11 Thread Dave Fisher
On Feb 11, 2014, at 12:43 PM, sebb wrote: > On 11 February 2014 17:01, Benson Margulies wrote: >> Could I suggest a focus on making the release process easier? That >> will benefit everybody, and serve as a platform for ongoing discussion >> about releases and cadences. >> >> It seems to me tha

Re: How can we support a faster release cadence?

2014-02-11 Thread Stephen Connolly
On 11 February 2014 22:01, Andrea Pescetti wrote: > Jim Jagielski wrote: > >> One reason for the 72hour rule is to ensure that no PMC >> member feels disenfranchised. ... >> >> PMCs are *inclusive*. The processes and procedures are >> designed to maintain that inclusivity. >> > > This is not 100%

Re: How can we support a faster release cadence?

2014-02-11 Thread Henri Yandell
On Tue, Feb 11, 2014 at 8:19 AM, Shane Curcuru wrote: > On 2/9/14 2:03 PM, Doug Cutting wrote: > >> On Sat, Feb 8, 2014 at 2:44 PM, Henri Yandell wrote: >> >>> * Go and fork the project code on GitHub. >>> * Put your changes in there and PR them up into the Apache codebase. >>> * If others want

Re: How can we support a faster release cadence?

2014-02-11 Thread Marvin Humphrey
On Tue, Feb 11, 2014 at 7:56 AM, Joseph Schaefer wrote: > The core question for me is do we want to continue > down this path of attempting to be all things to > all people with no common culture or values or processes, > or is there a floor somewhere. If there is, where > should it be? To my mi