maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.
Date Mon, 02 Jan 2017 16:53:28 GMT
The normal Apache process here is this: if someone finds a commit
sufficiently objectionable, as per CTR, they
https://www.apache.org/foundation/glossary.html#Veto it. It gets reverted
post haste, no vote is needed.


According to the Apache methodology, a change which has been made or
proposed may be made moot through the exercise of a veto by a committer to
the codebase <https://www.apache.org/foundation/glossary.html#Codebase> in
question. If the R-T-C
<https://www.apache.org/foundation/glossary.html#ReviewThenCommit> commit
policy is in effect, a veto prevents the change from being made. In either
the R-T-C or C-T-R
<https://www.apache.org/foundation/glossary.html#CommitThenReview>
environments,
a veto applied to a change that has already been made forces it to be
reverted. Vetos may not be overridden nor voted down, and only cease to
apply when the committer who issued the veto withdraws it. All vetos *must* be
accompanied by a valid technical justification; a veto without such a
justification is invalid; in case of doubt, deciding whether a technical
justification is valid is up to the PMC. Vetos force discussion and, if
supported, version control rollback or appropriate code changes. Vetoed
code commits are best reverted by the original committer, unless an urgent
solution is needed (e.g., build breakers). Vetos only apply to code
changes; they do not apply to procedural issues such as software releases.

On Mon, Jan 2, 2017 at 11:36 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> 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 <tibordigana@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message