Change is hard, we aren't a tiny org and we do have an opinion about how things should be done. That's all I'll say about the git stuff.
But let's face reality for a moment- Cordova has averaged one release a month for the past seven months. Why then is a three day window a dealbreaker? Sent from my iPhone > On Feb 13, 2014, at 5:04 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > > Not sure if it's a mischaracterization. I have the same understanding as > Benson that that many comments on git threads reflected the perception that > git/github are incompatible with ASF. Not the point however. > > What I see again is, for the most part, violent agreement that turns into > lengthy threads that have a ddos effect (at least on me). What I get is that: > * votes are important, no vote no release (little to debate on that, given > the current bylaws) > * the community *must* be included, hence the rationale for 72 hours votes > guideline > * the board is ok with shorter vote windows, provided the release > requirements are met *and* community is included > * the cordova community is willing to adapt to a process that satisfies the > ASF guidelines, but they would like to preserve their current style of > 'cadence releases' > > What I don't get is this: > * say a community reaches a consensus to provide weekly releases (or daily, > whatever cadence) > * say that they all know that the voting window is 12 hours (or 1 hour) > starting *always* on Wed as 12 am UTC. > Then how can one justify a claim that a release was pushed by the 'people in > the room'? Cadence release is not unheard of. There are communities who > release at a cadence of 4 years and the voting window is 24 hours, the Tue > after the first Mon in Nov [1]. > > * nobody could claim they are excluded, as the voting window is well known in > advance > * people (pmc or not) can decide in advance if they have bandwidth to > participate in testing the release and hence voting > * people can volunteer/announce in advance if they can/will participate in > testing the release, which is what the RM does in any project > * what goes in the release is dictated by the commits and the community has > plenty of ways to decide how to accomplish that > * changes are incremental (i.e. whatever changes since last week), so the > volume of work and expectations are known and manageable > * people can decide what the fate of failed releases is (redo, skip, etc). > * a project could even go as far as allowing such 'short' vote cycles only > via a unanimous and time bound (say quarterly) vote in the PMC. This way a > rogue group would only have a limited time to push their interests. A > disenfranchised PMC member could easily -1 short releases for the next > quarter. If the community cares about candence releases, it creates an > incentive for people to play nicely in the community. And there are other > ways, smarter people already suggested. > > It is not my place to judge nor my desire to advocate for or against cadence > releases. I saw a bunch of excellent comments and proposals in these > thread(s). Some volunteered to experiment too. What is the problem with such > an elusive solution, really? What is the perceived risk? > > My $0.02, > Hadrian > > [1] http://en.wikipedia.org/wiki/Election_Day_%28United_States%29 > > >> On 02/13/2014 08:40 AM, Joseph Schaefer wrote: >> That is a mischaracterization of the git story which was always about being >> able to support multiple version control tools. Yes people were concerned >> about the social side but we wouldn't be Apache without that debate. >> >> Same here. All you are seeing is some natural skepticism about the claims >> being made. The door is open though to a well considered proposal that this >> exercise should help refine. >> >> Sent from my iPhone >> >>> On Feb 13, 2014, at 7:58 AM, Benson Margulies <bimargul...@gmail.com> wrote: >>> >>> This conversation goes in a circle. I see two positions: >>> >>> 1: Cadence releases are inevitably incompatible with Apache community >>> values. >>> 2: Cadence releases are not inevitably incompatible with Apache >>> community values. >>> >>> People who take the first position see this desire to use cadence as >>> weakening of values and the brand. People who take the second position >>> are frustrated. >>> >>> Note the phrase, 'not inevitably'. No one here is claiming, in the >>> absence of an experiment, that this idea will inevitably lead to a >>> perfectly healthy expression of Apache Community values. >>> >>> This conversation reminds me of the early days of the git discussion. >>> At that time, some folks were convinced that 'git === fork culture'. >>> Since 'fork culture' is pretty clearly incompatible with Apache >>> community values, it took a very long time for us to decide to perform >>> an _experiment_ in git usage to see what would happen. OK, here we >>> are, the git experiment has been deemed a success. >>> >>> The following is utterly non-rhetorical. Something happened over the >>> course of long discussion to move from 'git is evil, go away' to >>> 'infra is willing to put effort into the infrastructure to support an >>> experiment.' What was it, and is there any hope of following that >>> path? >>> >>> >>> >>>>> On Thu, Feb 13, 2014 at 12:02 AM, Phil Steitz <phil.ste...@gmail.com> >>>>> wrote: >>>>>> On 2/12/14, 7:23 PM, Marvin Humphrey wrote: >>>>>> On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz <phil.ste...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> I know this looks old-fashioned, even downright anachronistic to >>>>>> "push-hourly-from-CI" people; but deciding *what* to release *as a >>>>>> community* is an important responsibility of ASF PMCs. Putting >>>>>> things on a rigid schedule basically skips this step, which, IMHO is >>>>>> a core part of our common culture and values. >>>>> Should projects who wish to release on a regular schedule avoid Apache? >>>> I agree with Joe that that is the wrong question to ask. The right >>>> question is what are the basic principles and values that >>>> *communities* should buy into when deciding to join Apache. I >>>> proposed a couple of them above. How releases happen, how policy >>>> compliance is assured are secondary - the main thing communities >>>> need to ask themselves when deciding to join the ASF is do they want >>>> to do open, community-based development the way it is done here. If >>>> cutting releases on a predetermined schedule is somehow a >>>> "requirement" for them, the first question to ask is "why" and if >>>> there is a good answer to that question then the second question is >>>> how do you do that in a way that is consistent our principles. >>>> >>>> Phil >>>>> Marvin Humphrey >>>>> . >
