OT: how you can have a release with a majority of the PMC voting -1 1. The reasons for voting -1 must not relate to the responsibility delegated by the board to the PMC with respect to the requirements of a release
2. The majority of votes cast by committers + PMC must be in favour of the release 3. At least 3 +1 votes from PMC members 4. A PMC member willing to stand up and perform the release finalisation steps 5. The release manager declaring the vote as passed Practically if the majority of the PMC is against the release on non-legal grounds but the majority of the committers is in favour it would signal a major crack in the *community* which would probably result in the board getting involved if left festering. Also the release manager would probably decide to cancel the vote where there is a significant minority against the release... so it is highly unlikely that such a release would happen... but it *could*! On Sat 31 Dec 2016 at 08:58, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > You have misunderstood the Apache way, imho > > Votes are only to *confirm* consensus... and the consensus is of the > *community* (ie everyone on the dev list who steps up to comment) > > When it comes to code changes, committers have a veto and the permission > to commit, so no code changes can happen without the approval of interested > committers. > > When it comes to releases, the PMC has been delegated certain legal > responsibilities by the board, so you cannot have a release without 3x +1 > by the PMC (technically doesn't matter how much of the PMC votes -1 as long > as the majority of votes cast by committers + PMC > 0 and you have at least > 3x +1 by PMC members... but a release manager doing so could be frowned on) > > > On Sat 31 Dec 2016 at 02:37, Christian Schulte <c...@schulte.it> wrote: > > Am 12/31/16 um 03:27 schrieb Christian Schulte: > > > Am 12/29/16 um 13:49 schrieb Robert Scholte: > > >> My worries are more about: how to manage which issues should be cherry > > >> picked and who decides that list. Otherwise we might end up in the same > > >> situation. E.g. do we have to do a vote on the branch (which might cover > > >> multiple issues but which are related to the same topic) to decide if it > > >> can be merged with the master? > > > > > > This is what I have in mind. I know my commits. What I would do as soon > > > as master has been reset would be to squash my commits as much as > > > possible and then cast a vote on specific issues (for each single commit > > > to be merged into master) with the exception that no response means +1. > > > So instead of the whole PMC needing to agree, not responding means "+1". > > > That also would mean that if e.g. two PMC members vote -1, all others > > > implicitly have voted +1 if they did not respond otherwise. WDYT? > > > > > > > Adding to this: I do not have a deep understanding of the Apache way of > > things. Personally, I do not get the point why the users of the software > > cannot take part in any of those decisions. I just may not get the > > point, of course. Citizens are asked to vote on election day, for > > example. Here it's like a dictatorship of those with the power to do so > > deciding the future of all others. Don't get me wrong on this please. > > English is not my native language and I may not have found the proper > > words here. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > Sent from my phone > -- Sent from my phone
