That is not how Apache works The PMC vote is only required for policy or releases. Outside of that, committer votes are what count.
Votes cast always trump votes not cast, and when it comes to commits, -1 is a veto... any -1 on a commit means thou shall not merge ... one should be very careful not to -1 a lot as it can be toxic to the community (at which point we then have to wake up the PMC or else the board might get involved) I think if we do this reset we need to have a plan. First step should be what was originally suggested, a simple switch from aether to resolver without other changes Then we can start fixing bugs in incremental releases after that On Sat 31 Dec 2016 at 02:27, Christian Schulte <c...@schulte.it> wrote: > 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? > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Sent from my phone
