Re: seconder on other fixes for Maven 3.5.3

Checkstyle fixes and Java 7 code (vs Guava) merged remaining to decide: MNG-6069 https://github.com/apache/maven/pull/153 commons-cli updates MNG-5378 https://github.com/apache/maven/pull/155 partial plexus-utils -> commons-lang There are some discussion pending on the first one, and for the

[GitHub] maven pull request #149: Upgrade maven-checkstyle-plugin to 3.0.0 (Checkstyl...

Github user asfgit closed the pull request at: https://github.com/apache/maven/pull/149 --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Second MNG-6353

Thanks, merged with https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=cd34b08d Robert On Sat, 10 Feb 2018 16:16:33 +0100, Robert Scholte wrote: Who wants to second https://github.com/apache/maven/compare/MNG-6353 ?

[GitHub] slachiewicz opened a new pull request #9: [DOXIA-570] Escape links to xml based figureGraphics image elements

slachiewicz opened a new pull request #9: [DOXIA-570] Escape links to xml based figureGraphics image elements URL: https://github.com/apache/maven-doxia/pull/9 This is an automated message from the Apache Git Service. To

[GitHub] slachiewicz opened a new pull request #8: [DOXIA-534] Migrate logging to slf4j and deprecate doxia-logging-api

slachiewicz opened a new pull request #8: [DOXIA-534] Migrate logging to slf4j and deprecate doxia-logging-api URL: https://github.com/apache/maven-doxia/pull/8 New version that deprecates doxia-logging This is an automated

Messos runs allocates too many Ubuntu executors on ASF Jenkins CI

I really have a problem to run my 11 parallel jobs on our Jenkins because Messos runs on most of the Ubuntu machines. Each Messos build takes cca 1 hour to complete. This does not make any problem for you? The Messos is triggered by a scheduler and not by a commit. Now I have to decide if I

Re: [DISCUSS] Do we want to keep “seconding” for core?

On Sun 11 Feb 2018 at 19:18, Robert Scholte wrote: > To me the most important reason for seconding is to have at least some > kind of consensus per issue before merging to master. > I don't want to get in the same situation again and if that means > seconding, then I'm fine

[GitHub] slachiewicz commented on issue #5: [DOXIA-534] Migrate logging to Sl4j

slachiewicz commented on issue #5: [DOXIA-534] Migrate logging to Sl4j URL: https://github.com/apache/maven-doxia/pull/5#issuecomment-364775373 New version with deprecation in #8 This is an automated message from the Apache

[GitHub] slachiewicz closed pull request #5: [DOXIA-534] Migrate logging to Sl4j

slachiewicz closed pull request #5: [DOXIA-534] Migrate logging to Sl4j URL: https://github.com/apache/maven-doxia/pull/5 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull

Re: [DISCUSS] Do we want to keep “seconding” for core?

To me the most important reason for seconding is to have at least some kind of consensus per issue before merging to master. I don't want to get in the same situation again and if that means seconding, then I'm fine with that even if it slows down the process. Quality is much more important.

Re: [DISCUSS] Do we want to keep “seconding” for core?

sure, the good reasons behind this process have to be understood Core really requires deeper review than any other component, because the impact is heavier and because reviewing is more complex then require more formal way to ask for others to take time to review. The other component IMHO that