On Thu, Feb 13, 2014 at 7:54 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > On Thursday, 13 February 2014, Joseph Schaefer <joe_schae...@yahoo.com> > wrote: > >> 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? > > > If you are looking to do one release per month, 72h is no problem IMHO > > If you are looking to do one release every 7 days (assuming there are > releasable changes) then 72h + 24h (before announce) is smelling > problematic... >
I don't see the problem there, unless you (or someone else) has a problem with overlapping release procedures, e.g., working on more then one release at a time, potentially having overlapping votes. All the 72-vote requirement does is mean there is a 72-hour delay for the first release. But if you want to have daily releases, then there is nothing illogical or impossible about doing that. It comes at some complexity and coordination cost, but that is the nature of the beast. The voting part doesn't make it more much complex. It just delays the first release. For example: Monday: Start vote on release N Tuesday: Code Wednesday: Start vote on release N+1 Thursday: Distribute release N Friday: Code Saturday: Distribute Release N+1 Sunday: Rest Monday: Start vote on Release N+2 and so on. Of course a problem in any release can bring the whole train to a halt. But that is true of real-world trains as well. Fix the problem, restart, but know that there would be a 72-hour delay before the releases come out again. Not a bad thing, necessarily, to have a pause like that when recovering from a failed released, IMHO. Regards, -Rob > I am proposing the Maven try weekly releases for our 3.2.x line after we > get our first 3.2.x release done and review after 3 months... We'll see > what our community feels about that suggestion... It may go nowhere if the > community doesn't like it... But I do feel that we are past the point of > speculating and that some project needs to try the experiment. > > >> 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 > > > > -- > Sent from my phone
