incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Shipping binary file in CloudStack release
Date Wed, 31 Oct 2012 17:07:28 GMT
Thanks for the clarification Roy.

On 31 October 2012 05:29, Roy T. Fielding <> wrote:

> [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.
> ....Roy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message