On 14 February 2014 20:39, Rob Weir <robw...@apache.org> wrote: > 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 >
+1 for showing how easy a problem can be solved, when putting it in table form and not make it a political issue. rgds jan I. > > 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 >
