community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: How can we support a faster release cadence?
Date Fri, 14 Feb 2014 00:54:21 GMT
On Thursday, 13 February 2014, Joseph Schaefer <joe_schaefer@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 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 <hzbarcea@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 <bimargulies@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message