Re: [VOTE] Apache DeviceMap Data 1.0.1 incubating
Hi Justin, On Sun, Sep 28, 2014 at 5:25 PM, Justin Mclean jus...@classsoftware.com wrote: ...I see that initial device data was donated by OpenDDR LLC is in CREDITS, should something be in NOTICE about this? Would depend on what the was the original license was right?... Thanks for your vote - the donation is documented in https://issues.apache.org/jira/browse/DMAP-11 and there hasn't been a requirement to include anything in the NOTICE file, so I think it's fine as is. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Johnzon 0.1-incubating release
On 28 September 2014 22:31, Hendrik Dev hendrikde...@gmail.com wrote: So the project passed with 6 +1 votes (at least 3 of them binding from Romain Manni-Bucau, Justin Mclean and Daniel Kulp) and no -1 votes. See http://markmail.org/thread/2tnh43qokzj3hiwa and http://markmail.org/thread/g5etfukwi4av6kuk As of now also the incubator vote passed with at least 3 binding votes from Romain Manni-Bucau, Justin Mclean and Mark Struberg and no -1 votes (until now). We would like to ask the IPMC and incubator people to review the release within the next 72 hours and if we get no -1 votes then the vote passed. Thanks Hendrik On Tue, Sep 23, 2014 at 8:19 PM, Hendrik Dev hendrikde...@gmail.com wrote: I've created a 0.1-incubating release candidate, with the following artifacts up for a project vote: Git tag for the release is https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=tag;h=refs/tags/v0.1-incubating Git tags are not immutable Please include the hash for the tag in vote e-mails, both for the reviewers and for the historical record. Maven staging repo: https://repository.apache.org/content/repositories/orgapachejohnzon-1000/ Source release: https://repository.apache.org/content/repositories/orgapachejohnzon-1000/org/apache/johnzon/johnzon/0.1-incubating/johnzon-0.1-incubating-source-release.zip The NOTICE file contains the following text: Please see LICENSE for additional copyright and licensing information. This is not required, and should be removed. (not a blocker for this release) The KEYS file does not really belong in the source release. The KEYS file has to be available from the ASF mirror host (*) This is derived from https://dist.apache.org/repos/dist/release/incubator/johnzon/ so the canonical source for KEYS should be maintained there, not in the source repo. The Git copy should be dropped (after merging any missing keys) Not a blocker. PGP release keys (signed using 22D7F6EC): http://www.apache.org/dist/incubator/johnzon/KEYS (*) this is the file which is published to consumers so they can check sigs The vote will be open for at least 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here is my +1 (non binding) Thanks Hendrik -- Hendrik Saly (salyh, hendrikdev22) @hendrikdev22 PGP: 0x22D7F6EC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Apache DeviceMap Data 1.0.1 incubating
This release passes with three +1 binding votes and no -1 votes: The +1 votes were from: Bertrand Delacretaz Kevan Miller Justin Mclean Thanks to everyone who voted and provided feedback! From: Reza reza.nagh...@yahoo.com.INVALID To: Incubator General general@incubator.apache.org Sent: Tuesday, September 23, 2014 12:11 PM Subject: [VOTE] Apache DeviceMap Data 1.0.1 incubating This is the second device data release for DeviceMap. This release contains various new devices and generic device class additions: https://issues.apache.org/jira/browse/DMAP/fixforversion/12327454/ The project vote is here: http://markmail.org/message/c2wvexsa7ed46n65 It passed with +3 PPMC and +1 IPMC (Kevan Miller) The release tag is located here: http://svn.apache.org/viewvc/incubator/devicemap/tags/releases/devicemap-data-1.0.1/ Release artifacts: http://devicemap-vm.apache.org/releases/data-1.0.1/ Please vote to approve this release. Voting will close in 72 hours (Friday Sept 26 2014). [ ] +1 Approve the release [ ] 0 No opinion [ ] -1 Don't release, because ... Thanks!
Re: Committer Voting and Vetos
Understand there is a radical difference between majority, consensus and unanimity. The HTTP Server project has successfully operated by unanimity, although many of us have experience of having the single holdout block progress. I don't believe majority is sufficient in these sorts of matters. In most projects, contributors are part of one or two major organizational players. That vocal minority protects a valued third voice. But an intractable project member is also an issue. If you are looking for unanimity in the face of an obstructionist, your choices are to move toward plurality or consensus ... or drop an obstructionist from the PMC roster. The HTTP Server PMC has succeeded in working through these issues without evicting a project member, and continuing to make progress. Noah Slater nsla...@apache.org wrote: Another way of wording this would be: the CouchDB community feels that for non-technical decisions, a single -1 vote should never block a majority consensus. The idea being that if the reasons for the -1 vote were compelling enough, others would change their position. It happened recently on a PMC I sit on. Many people were in favour of an action, and one person was against. The action was blocked. If this happens regularly enough, you can end up never taking any actions. Of course, how close to absolute consensus you want to require depends on two things: - The nature of the decision - The shape of your community For young projects, I would recommend being strict, and then loosening up if you start to have problems. On Friday, 26 September 2014, Noah Slater nsla...@apache.org wrote: As the primary author of the CouchDB bylaws, I will weigh in here. Agree with Ross on the discussion stuff. We actually codify this attitude in our bylaws. http://couchdb.apache.org/bylaws.html#decisions Specifically, we (CouchDB) see voting as the failure mode of a discussion (a useful one non-the-less), or as a last-step requirement to officiate a particular set of project-level decisions (that are fully enumerated in the bylaws). Wrt to the approval model of voting in committers... cf. http://couchdb.apache.org/bylaws.html#approval We chose lazy 2/3 majority, i.e. requires three binding +1 votes and twice as many binding +1 votes as binding -1 votes. Very specifically (and this is spelled out in the bylaws) with the CouchDB project, we only want a -1 vote to have veto power within the context of code review on a release branch. There are historical reasons for this. We found that some members of our community were casting -1 votes fairly carelessly, and expecting to be able to halt what the majority of the PMC felt were beneficial initiatives (including elections). For us, moving to lazy majority or lazy 2/3 majority for most big decisions was a way to improve our decision-making ability, allowing us to actually make changes to the project, whereas before we had been quite sclerotic. As Joe correctly hits on, some of this was due to me and others attempting to make some fairly large changes to the project since about 2012, when we ran into some major issues. One of the changes I was driving was the redefinition of what a committer is. I wanted to lower the barrier to entry. Whereas before we tended to only elect people who were contributing code, I wanted to expand that and start electing people who were doing other things, like documentation, translation, marketing, design, community management, and so on. This is just one example. But making these sorts of changes (essentially things that require cultural shifts) is hard when one person is able cast a -1 vote and shut down an initiative that everyone else is behind. On 26 September 2014 16:46, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com javascript:; wrote: Trying to build on Joes answer below Given that the ASF is about consensus the vote for.at should be mostly irrelevant. Nominations should have been thoroughly discussed before the vote is called. The vote should be a formality required by the bylaws to demonstrate consensus. What I mean is there should never be a veto vote cast. The PMC should have already discussed the reasons why someone has their concerns. Those reasons should either have been supported (and no vote called) or talked through and withdrawn. An example... An individual was proposed, the PMC discussed. Two people felt it was too early because the individual had bit contributed much code, and thus their code quality could bit be assessed. Everyone recognized the individual was contributing to user support, documentation, design etc. In order to have the objections removed a PMC member offered to mentor the new committee should code contributions prove to be problematic. This approach was agreed, the vote was called and passed. That individual is now a member of the foundation. Had we bot brought then in at the earliest
Re: Committer Voting and Vetos
On Mon, Sep 29, 2014 at 8:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: The HTTP Server PMC has succeeded in working through these issues without evicting a project member, and continuing to make progress. There is a lot of credit due for this. Of course, there are different stresses on each project. Some projects have large commercial interests at stake. Others have incredibly little directly at stake. The problems in these different groups are often very different. My own limited experience is that people often play together better when there is much at stake, except when there is a perception of a zero sum game. When little is at stake, just about anybody can afford to be an ass. This observation has been attributed to a huge number of people [1]. I like the idea that Samuel Johnson was the originator of the core idea. http://quoteinvestigator.com/2013/08/18/acad-politics/
