community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: How can we support a faster release cadence?
Date Tue, 11 Feb 2014 17:01:26 GMT
Could I suggest a focus on making the release process easier? That
will benefit everybody, and serve as a platform for ongoing discussion
about releases and cadences.

It seems to me that we could make voters' jobs easier. This would help
get releases approved _in 72 hours_, to start with.

We ask voters to participate in a business decision by;

1. being aware of the ongoing work of the community
2. checking the signature
3. building and running enough tests to be willing to endorse that
release as a product of the community

At the start of this thread, someone asked: "If a trusted machine
validated the signature, built the package, and ran the tests, could a
responsible PMC member vote +1 on the basis of trusting the machine?"
After all, all many voters do is to run the tests in the package, and
if a someone has committed changes to denature them, the voter might
well not notice.

All of this should sit on the platform of my first point above: I
submit that a person who has been paying no attention to commits and
discussions has no business swooping in and voting on a package based
on the other two steps.

On Tue, Feb 11, 2014 at 11:19 AM, Shane Curcuru <> wrote:
> On 2/9/14 2:03 PM, Doug Cutting wrote:
>> On Sat, Feb 8, 2014 at 2:44 PM, Henri Yandell <> wrote:
>>> * 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.
>> Keep in mind that if this is in any way a PMC activity then it is part
>> of Apache trying to circumvent the rest of Apache, i.e., not advised.
>> A distinct legal entity may indeed fork, re-brand, alter and release
>> any Apache project using policies it prefers, but this must be clearly
>> separate from any Apache project.  A subset of a PMC acting as
>> individuals would be murky territory if they share no common legal
>> entity outside Apache.
>> Doug
> The key point is: who is the "we" that the world perceives doing this? This
> whole discussion really underscores the importance of trademarks and the
> Apache brand.
> We're quite happy for anyone to take our code and ship it just about however
> they like.  But they can't call it an Apache project: only a PMC here at
> Apache can do that.  While the original reason for most ASF release,
> branding, legal, etc. policies is to ensure our legal safety, the very real
> effect of these policies and their consistent application in PMCs is that
> our projects following these policies are *seen by the rest of the world* as
> being "Apache projects".
> - Shane

View raw message