community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: How can we support a faster release cadence?
Date Tue, 11 Feb 2014 22:04:02 GMT

On Feb 11, 2014, at 12:43 PM, sebb wrote:

> On 11 February 2014 17:01, Benson Margulies <> wrote:
>> 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
> + hashes
>> 3. building and running enough tests to be willing to endorse that
>> release as a product of the community
> 4. Checking that the NOTICE & LICENSE files are appropriate to the
> release artifacts that contain them.
> 5. Checking that the contents of the source release agree with the SCM
> tag (there should be nothing in the source release that is not in SCM
> - or perhaps directly derived therefrom, but that is unusual)
>> 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.
> I agree if the vote is +1
> However, I don't think one should disallow reports of packaging bugs
> or test failures - these can be picked up by anyone.
> Also note that whatever is used to check the packaging and release
> should be entirely independent of the packaging mechanism.
> This is necessary to avoid common-mode failures (if that is the correct term).


Here is another scenario to think about. If a PMC bases their votes on Tooling only and not
on a careful review of tooling inputs then there can be trouble.

For example. RAT is a great tool, but in checking a release you ought to look into the RAT
excludes plus any changes to that file. You then need to manually check those files to make
sure it still makes sense to exclude those. RAT excludes can hide inadvertent problems with
the release.

The tooling is only as good as its input and it is important to check that during your testing
before casting your release vote. The most important -1 on a release is one where there is
an IP problem. A PMC that is not pressured by cadence will almost automatically treat even
the smallest IP related -1 as a valid VETO. The trouble will be fixed and the release re-spun.

What happens when the cadence is more important to the PMC? The hiccup of a missed cycle is
worth it. The community will learn that IP relaly does matter and even tiny infractions are
cleaned in a responsibly quick way.

If you are doing it that way and can prove it then the PMC is doing its human best. If anyone
calls the PMC on IP or license an established behavior of respect goes along way. Let's be
sure to leave the credence intact.


>> 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
>>>>> 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
>>>>> 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