[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 <chip.child...@sungard.com> wrote: >> On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <nsla...@apache.org> 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] http://www.apache.org/dev/release.html#approving-a-release > > > 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
