Well I'm not happy with how development has evolved here, hence my rather vocal stepping up tovtr and pull core back into order.
If you want to do a reset, you'll need a vote from committers ok-zing the reset. Do NOT call a vote without ensuring that you have consensus *first*. Votes should be used to *confirm* consensus not establish it. When you have a vote first, it divides the community into the +1's and the -1's. When you have a discussion first, you can identify the concerns of people likely to vote -1 up front and modify the proposal to include them such that they become a 0 or even a +1. That will grow and strengthen our community. I would hate to see us move to RTC, as that requires a higher level of involvement from committers in order to get changes made... though it seems committers have been running as C rather than CTR... where is the evidence of the TRs? With CTR, each commit is an implicit vote where the absence of a -1 after 72h implies approval. Another option, rather than a reset is you could *veto* the commit. Vote -1 on the commit, by replying to the commit email and state your reasoning. The original committer is then required to either address your concerns or revert the commit. Vetoing an individual commit is normally seen as rude, but if it is the correct thing to do, then do it. The situation on core+integration-tests is somewhat different. A lot of those commits are probably fine... but just should not be in the first release after 3.3.9... and reverting only to restore again later will only further complicate a history that already has quite a few reverts and reworks... in that regard I feel a reset is appropriate... and so far I have not seen any disagreement (such that I expect to call a vote on Wednesday - giving a little more seasonal time for confirmation of consensus) I do think we need to get into at least a more "branchy" development style... if not full fledged PRs, though we need better CI support to assist (again I am working on that for core+integration-tests) On Mon 2 Jan 2017 at 14:42, Tibor Digana <tibordig...@apache.org> wrote: > I also have such feeling that Maven became a playground. > > Last week I saw it in reality and after Robert told me we made playground > > in our sources I could not believe this could happen in such professional > > project like Maven. > > > > I would appreciate it if the change [1] > > e5a6b9c8d4f514100a01dea2acf1fb059e294968 was reverted in Surefire and a new > > pull request was open at GitHub making the code review. > > I use to do this with myself with big changes and I am waiting for anyone > > in the PR. We are doing the same with one excellent guy from another ASF > > project who is supporting us with JUnit 5 addons and this works pretty > well. > > > > The situation in Surefire is quite ambitious to release Versions 2.19.2 and > > 3.0.0-RC1 in parallel with 2.19.3 JDK9 support and JUnit 5 support now in > > January. > > > > The problem is that these Surefire three plugins are so easy to crash with > > whatever changes and therefore I implemented dumping internal errors to > > dump files which will help us investigate two Jira issues - critical and > > blocker. And there are much more thinks to talk about the features... > > > > I would really appreciate if we could behave like ordinal users in our > > project and provide a pull request in GitHub and call for code review. > > This does not mean only Surefire. > > > > So now please revert last change [1] and let's start from the ground. > > We should again learn from the beginning and start communicating in the > > community; otherwise this is the end of the project. > > > > [1] > > > https://git1-us-west.apache.org/repos/asf?p=maven-surefire.git&a=commit&h=e5a6b9c8d4f514100a01dea2acf1fb059e294968 > > > > We can talk about more visions, or I can open Wiki for such talks which I > > think we will appreciate because everybody can add her/his visions. > > > > WDYT? > > > > Cheers > > Tibor > > -- Sent from my phone
