incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Shipping binary file in CloudStack release
Date Wed, 31 Oct 2012 05:29:29 GMT
[generic incubator comments -- nothing specific to CloudStack] ...

On Oct 29, 2012, at 8:01 AM, Noah Slater wrote:
> On 29 October 2012 14:48, Chip Childers <> wrote:
>> On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <> wrote:
>>> But regardless, you couldn't. A single -1 vote would be
>>> enough to block the release. Binding or not binding. It doesn't matter. If
>>> somebody expresses a real, and justified, concern about the artefact, then
>>> you don't release until you've addressed that concern.
>> If that's true, then should the release policy [1] be updated?
>> [1]
> Perhaps.
> I know I started out RMing with the idea that I just needed to collect more
> +1 votes than -1 votes. But I think that's broken in practice. I think if
> you have a valid, justified, -1 vote, and you release without addressing
> it, then there is something SERIOUSLY wrong.

It entirely depends on why the -1 is cast.

Release votes are lazy majority decisions.  They are not at all like
design decisions or adding a new committer.  A person could -1 a release
simply because they are working on a new feature and want the group
to wait until it can be included.  These are matters of opinion.

If someone casts a -1 because something is seriously wrong, then
we expect the rest of the PMC to wake up and say -1 as well.
If they don't, then it isn't seriously wrong even if one or a
few people think so.  IOW, if it is a serious issue then we can
expect the majority to agree that it is a serious issue.  There
is no need to change the rules to accomplish that.

An RM can choose to stop working on a release at any time.
We are all volunteers. However, the release decision is made
by the PMC; if a vote has completed on an artifact, then
that artifact can be copied to dist by anyone in the PMC.
If something really bad is found in a voted-on-but-not-yet-announced
release, then we expect the PMC to work together to ditch the old
artifacts, fix the problem(s), and start again with a new
version number.  If they don't, the project has a much larger
problem than anything we might find in a release.

Note that there has never been a case where a real problem is
found and the rest of the group hasn't immediately shut down
the release.  However, there have been cases where individuals
have poisoned an entire project simply by dragging their feet on
the release process for the sake of their own work or world-view.

A release vote is required to be a majority decision, rather than
a consensus decision, because Apache understands group dynamics.
That cork is meant to be popped.  It is better for the group
that it be popped on a regular basis, where regular is
defined by the majority of the group.  The more, the merrier.
Adding glue around the cork to make sure it doesn't pop, unless
we really really mean it, is not a good plan.  We are far more
likely to be hurt by a project that can't release than a project
that occasionally releases too soon.  Folks often lose sight of
that when focused on fixing a specific issue.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message