Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: pass (athena.apache.org: domain of
 stephen.alan.connolly@gmail.com designates 209.85.160.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALGG8z1NS=Lg==moEYRk++Uh6YCKysJfPXd5BwiwiY3JeHOrJQ@mail.gmail.com>
References: 
 <CA+nPnMxOBePvV6urfFgqHFww=-Bn0XRk+vAyEtsfqKqxrRLSBA@mail.gmail.com>
	<CALGG8z1NS=Lg==moEYRk++Uh6YCKysJfPXd5BwiwiY3JeHOrJQ@mail.gmail.com>
Date: Sat, 8 Feb 2014 23:26:42 +0000
Message-ID: 
 <CA+nPnMw5KP+MO_5K74mVvVvXG33yt_0i79iHKVKTmos6BNNV3Q@mail.gmail.com>
Subject: Re: How can we support a faster release cadence?
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: "dev@community.apache.org" <dev@community.apache.org>
Content-Type: multipart/alternative; boundary=047d7b10cb8970826904f1ed7093

--047d7b10cb8970826904f1ed7093
Content-Type: text/plain; charset=ISO-8859-1

But what if the community wants Apache to have such a rapid cadence?

By forcing the community to decamp to GitHub, then what are we saying to
that community? Sorry we may value community over code, but we value
procedure over both?

If that is the answer, then so be it, let's change our mantra from
"community over code" to "policies and procedures over community over
code"... But that is not the foundation I thought I was joining

There are only some hard and fast rules at the ASF... 72h for a vote is not
a hard and fast rule (you just need a good reason for why you are going
shorter and from what I have seen, the board would probably be ok as long
as protections are put in place to safeguard the community)

So the only hard rule per se, is that the PMC must do their IP diligence...
What I don't want to see is a PMC taking the "easy" way out and pretending
that thy download an check the source bundle for IP... I suspect there are
enough binding votes cast having skimped on that criteria... So we need to
make it easier for the PMC members to do their responsibility and verify
the IP...

Sure we can live in the dark and say that moving faster is not "the Apache
way"... But how does that protect the foundation...

Faster release cadence is about raising the bar in general too... Not just
about helping some projects "dodge" release vote requirements

- Stephen

On Saturday, 8 February 2014, Henri Yandell <henri@yandell.org> wrote:

> If you want to have a faster release cadence, then I think the answer is
> for _you_ (not Apache) to have a faster release cadence. It seems easy to
> look at Apache rules for releases and Linux rules for releases (as an
> underpinning for the features found in Git) and treat them as incompatible,
> but I don't think they should be.
>
> * Go and fork the project code on GitHub.
> * Put your changes in there and PR them up into the Apache codebase.
> * If others want to, they can PR the code to you, and then you can PR the
> code up to the codebase (or the group of you could work as a community
> preparing PRs).
> * The one pushing into the Apache codebase needs to be confident that the
> code is covered by CLAs.
> * You can release in GitHub whenever you want.
> * The Apache release happens less often and follows the rules.
>
> We have some issues to 'defend' against:
>
> * Trademark understanding so that a project's releases on GitHub do not
> appear as being from Apache.
> * Making sure the system is not used for exclusionary reasons (though
> they'll often identify community problems as a root cause anyway).
>
> It's no different than what commercial companies are doing already, either
> by having internal forks or an 'upsell' public version; with both cases
> taking time for patches to work their way back in. Why not have subsets of
> the PMC doing the same?
>
> This takes the legal arguments out and gets us more focused on the 'but a
> singleton community is the apache way' gut unhappiness.
>
> Hen
>


-- 
Sent from my phone

--047d7b10cb8970826904f1ed7093--