community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: How can we support a faster release cadence?
Date Fri, 14 Feb 2014 19:41:44 GMT
On 14 February 2014 20:39, Rob Weir <robweir@apache.org> wrote:

> On Thu, Feb 13, 2014 at 7:54 PM, Stephen Connolly
> <stephen.alan.connolly@gmail.com> wrote:
> > 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 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 <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