Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte]

Am 12/28/16 um 14:33 schrieb Robert Scholte:
> ...implement MNG-5739.

Exactly. In model version 5.0.0. Until then, project and plugin and
extension resolution should behave the same. It makes no sense to have
different resolution strategies no-one knows about. MNG-5739 is not
about plugin runtime classpath construction!



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte]

Am 12/28/16 um 14:33 schrieb Robert Scholte:
> ...revert MNG-6135.

Well. If I would be a jerk, I would come up and say: But this is how
Maven 2 behaved and Maven 3 must behave the same way or I will vote -1
on the release. MNG-6135 has been requested by Igor Fedorenko. Ask him
about it.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte]

Am 12/28/16 um 11:44 schrieb Robert Scholte:
> So can we remove the commandline option?

IMHO, yes. It's just one commit to revert on Maven master. I would still
like to wait a bit on my last comment on MNG-6139.




Mark?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #137: Fix SUREFIRE-1239

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/137
  
@jsdima 
I am interested in this problem because as you said the plugin hangs.  Why 
the plugin hanged, do you have explanation?
Did you run the build with your patch? It means `mvn -P run-its install`.
The issue [1] you pointed out happens after your fix or without it?
[1] `[ERROR] Failed to execute goal...`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Stephen Connolly]

This got lost on the PMC list by mistake

On Thu 29 Dec 2016 at 14:33, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I don't think we need to vote each change, but I do think we need to look
> at a more RTC like model for bigger impact changes.
>
> I think we can trust developer judgement once we have some guidance in
> place
>
> On Thu 29 Dec 2016 at 14:07, Igor Fedorenko  wrote:
>
> I agree with the proposed plan and also confirmed both commits SHA1s.
>
>
>
> I think/hope that forcing all changes to feature branches and require a
>
> vote to merge isn't necessary.
>
>
>
> I think changes that affect existing integration tests should require a
>
> vote but I don't think it's practical to discuss/vote all changes. We
>
> should ask developers to describe "bigger" changes on the dev list
>
> before they commit, however, and other developers can request the change
>
> go through a feature branch and vote process.  "Smaller" changes can go
>
> right in. Of course, "big" and "small" is subjective, but I think we
>
> need to assume Maven developers generally know what they are doing ;-)
>
>
>
> We also need to ask that each commit on master represents a single
>
> complete logical change, to make individual commits easy to understand
>
> and review. I honestly don't think we have the manpower to review and
>
> groom each commit to perfection upfront, so it is inevitable that some
>
> commits will require follow-up changes, but I hope these will be
>
> exceptions and most of commits on master will be clean and
>
> self-contained changes.
>
>
>
> --
>
> Regards,
>
> Igor
>
>
>
> On Thu, Dec 29, 2016, at 07:49 AM, Robert Scholte wrote:
>
> > thanks Stephen for picking this up.
>
> >
>
> > SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03
>
> > * [maven-release-plugin] prepare for next development iteration
>
> >
>
> > Yes, this is the hash I would expect to revert to.
>
> > Based on the date I would expect that maven-its should be reset to
>
> >
>
> > SHA-1: 94bd771c88cc96014ca0ddaa07ac6f778b3c7501
>
> > * [MNG-5840] Argh! tests added but not added to suite
>
> >
>
> > I like the idea of pushing to 3.5.0 to indicate there was something with
>
> > 3.4.x
>
> >
>
> > 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?
>
> >
>
> > Robert
>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Michael Osipov]

Am 2016-12-29 um 20:41 schrieb Christian Schulte:

Am 12/29/16 um 16:04 schrieb Michael Osipov:

Am 2016-12-29 um 12:18 schrieb Stephen Connolly:

On ASF infra, our master branch is supposed to be a protected branch and
thus cannot be reset or force-pushed without an INFRA ticket.

If we want to reset our master branch in order to clean out the history of
the many changes and reverts to and fro etc, we thus need an INFRA ticket
raised.

INFRA should not act on such a ticket without the results of a vote of the
committers that has at least three binding votes from the PMC (i.e. the
majority of votes cast must be in favour and at least three PMC members
must have voted in favour)

Votes are a great way to *confirm* consensus, but a horrible way to build a
community or establish consensus. We should only ever have a vote thread
once the consensus seems to be established.

To establish consensus we use a discuss thread.

Please refrain from assigning blame, we want to grow our community not
shrink it. The shorty endorphin rush you get from assigning blame or
performing The Dance Of I Told You So™ will require repeated hits to
maintain which will only lead to a more toxic community.

We have not been good at maintaining our CI infrastructure:

* As a consequence, some people have been developing on master rather than
on branches in order to ensure that their development gets the benefit of
the integration tests

* This has lead to a lot of micro commits and effectively revert commits on
master making it hard to track what actually has changed and what has
actually been fixed.

* Additionally `git blame` probably now could end up confusing people
trying to understand the rationale for some changes

We have not been good at maintaining our Integration tests:

* As a consequence it has been hard to get our CI infrastructure working
effectively

* As a consequence, people have been forced to leverage a single branch for
CI testing

We have not been good at developing bigger changes in a branch

etc.

I could go on.

My belief is that confidence in 3.4.0 has been eroded.

I propose that we reset master back
to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
master for the integration tests, and then immediately commit a dummy
commit so that nobody accidentally does a fast-forward push.

Then we can cherry pick the changes that were on the old master that we
want to have in 3.4.0

This will probably also involve:

* Fixing the CI infrastructure (I favour using a pipeline multibranch
project so that branch development is easier,
https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
trying to prototype this... currently failing because "windows")

* Switching to a culture of branch / PR development for all committers

* Better providing rationale for changes, e.g. we need a succinct
description of the actual regression between 2.x and 3.x in resolution of
dependencies of plugins as well as actual easy to understand tests that
demonstrate the behaviour *and* show that it is an actual regression

* etc

But the first step in that would be to reset master...

So...

Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?

What is the correct hash for the integration tests?

Do we want to do this?

What else should we change about our processes to prevent the need to do
this again?

Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
that this was a reboot version and any 3.4.x stuff is thus easy to detect
and filter?


While I do agree to reset master on that commit and we do have deficits
here, there are some open questions:

1. Who and when is going to solve the CI problem? I personally do not
even have the permission on Jenkins to create a job to test my branch
stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve
flexibility.

2. Commit amount:

$ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l
328

How do you want to replay non-breaking commits onto the new master?
Will you ask every committer to replay their commits?

3.4 is burned soil. Let's skip it.



We should take this opportunity to also squash JIRA issues. There have
been various JIRA tickes regarding the launcher scripts, for example. We
should create a new JIRA issue superceding all of them and then squash
all commits and make all of those commits for multiple JIRA issues just
one commit on master for that one JIRA issue.


I wouldn't do that. It would kill traceability for the reporter. If one 
ticket required two or more commits, this should be squashed or course. 
I'd like to keep changes to working commits as little as possible. 
Especially because one needs to change all change comments on JIRA due 
to new hashes.


Michael



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Christian Schulte]

Am 12/29/16 um 16:04 schrieb Michael Osipov:
> Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
>> On ASF infra, our master branch is supposed to be a protected branch and
>> thus cannot be reset or force-pushed without an INFRA ticket.
>>
>> If we want to reset our master branch in order to clean out the history of
>> the many changes and reverts to and fro etc, we thus need an INFRA ticket
>> raised.
>>
>> INFRA should not act on such a ticket without the results of a vote of the
>> committers that has at least three binding votes from the PMC (i.e. the
>> majority of votes cast must be in favour and at least three PMC members
>> must have voted in favour)
>>
>> Votes are a great way to *confirm* consensus, but a horrible way to build a
>> community or establish consensus. We should only ever have a vote thread
>> once the consensus seems to be established.
>>
>> To establish consensus we use a discuss thread.
>>
>> Please refrain from assigning blame, we want to grow our community not
>> shrink it. The shorty endorphin rush you get from assigning blame or
>> performing The Dance Of I Told You So™ will require repeated hits to
>> maintain which will only lead to a more toxic community.
>>
>> We have not been good at maintaining our CI infrastructure:
>>
>> * As a consequence, some people have been developing on master rather than
>> on branches in order to ensure that their development gets the benefit of
>> the integration tests
>>
>> * This has lead to a lot of micro commits and effectively revert commits on
>> master making it hard to track what actually has changed and what has
>> actually been fixed.
>>
>> * Additionally `git blame` probably now could end up confusing people
>> trying to understand the rationale for some changes
>>
>> We have not been good at maintaining our Integration tests:
>>
>> * As a consequence it has been hard to get our CI infrastructure working
>> effectively
>>
>> * As a consequence, people have been forced to leverage a single branch for
>> CI testing
>>
>> We have not been good at developing bigger changes in a branch
>>
>> etc.
>>
>> I could go on.
>>
>> My belief is that confidence in 3.4.0 has been eroded.
>>
>> I propose that we reset master back
>> to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
>> master for the integration tests, and then immediately commit a dummy
>> commit so that nobody accidentally does a fast-forward push.
>>
>> Then we can cherry pick the changes that were on the old master that we
>> want to have in 3.4.0
>>
>> This will probably also involve:
>>
>> * Fixing the CI infrastructure (I favour using a pipeline multibranch
>> project so that branch development is easier,
>> https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
>> trying to prototype this... currently failing because "windows")
>>
>> * Switching to a culture of branch / PR development for all committers
>>
>> * Better providing rationale for changes, e.g. we need a succinct
>> description of the actual regression between 2.x and 3.x in resolution of
>> dependencies of plugins as well as actual easy to understand tests that
>> demonstrate the behaviour *and* show that it is an actual regression
>>
>> * etc
>>
>> But the first step in that would be to reset master...
>>
>> So...
>>
>> Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?
>>
>> What is the correct hash for the integration tests?
>>
>> Do we want to do this?
>>
>> What else should we change about our processes to prevent the need to do
>> this again?
>>
>> Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
>> that this was a reboot version and any 3.4.x stuff is thus easy to detect
>> and filter?
> 
> While I do agree to reset master on that commit and we do have deficits 
> here, there are some open questions:
> 
> 1. Who and when is going to solve the CI problem? I personally do not 
> even have the permission on Jenkins to create a job to test my branch 
> stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve 
> flexibility.
> 
> 2. Commit amount:
>> $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l
>> 328
> How do you want to replay non-breaking commits onto the new master? 
> Will you ask every committer to replay their commits?
> 
> 3.4 is burned soil. Let's skip it.
> 

We should take this opportunity to also squash JIRA issues. There have
been various JIRA tickes regarding the launcher scripts, for example. We
should create a new JIRA issue superceding all of them and then squash
all commits and make all of those commits for multiple JIRA issues just
one commit on master for that one JIRA issue.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Christian Schulte]

Am 12/29/16 um 18:57 schrieb Hervé BOUTEMY:
> perhaps maven-resolver will require same reset

No need for this. Reverting MRESOLVER-8 and MRESOLVER-9 will be
sufficient. Those are one-line style of commits. The rest of the commits
do not change any behaviour.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Christian Schulte]

Am 12/29/16 um 12:18 schrieb Stephen Connolly:
> I propose that we reset master back
> to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
> master for the integration tests, and then immediately commit a dummy
> commit so that nobody accidentally does a fast-forward push.

+1 for the reset from me (committer) as long as this does not mean
current master is lost. So please create a branch of current master
before resetting it. There are a lof of issues that can go in unchanged
afterwards.

> Then we can cherry pick the changes that were on the old master that we
> want to have in 3.4.0

I will squash all my commits before picking them by issue. So there will
be only one commit in master for a given issue. And I will not do
anything like that until there is a clear and final list of issues to go
in. If you take a look at MNG-5971, I committed, then started a release
build on Jenkins and then asked the parties involved in MNG-5971 to
test. I am not sure anyone would have build the core himself from a
branch. So I am -1 for personal branches. Let master be the release
branch but please let there be a branch everyone working on the next
release can commit to so that things get tested during development as
much as possible. You can take the recent discussions on dev@ due to
3.4.0-SNAPSHOT as an example for what I mean. All discussions have led
to issues in JIRA. Personally I rate that something positive. Especially
if you take a look at how those issues may affect fundamental Maven design.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Releasing Wagon 2.11

[Christian Schulte]

Am 12/28/16 um 22:50 schrieb Robert Scholte:
> "That's always been that way."
> Well, apparently not. Maybe it was documented that way, but I expect that  
> users did their dependency management which felt natural and which worked.

I created an issue in JIRA to track this:


It has an example project attached demonstrating what is going on using
versions and not scopes or the optional flag. I think that's the real
issue at hand. It just happens that managing something transitive to
something non-transitive starts to work correctly in Maven 3.4+ and this
produces compilation errors in Wagon. No-one is noticing those
dependency management overrides are only in effect locally during
building the module declaring them an nowhere else.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Releasing Wagon 2.11

[Guillaume Boué]

I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the Java 
code should create a sparse file to have things faster. Using setLength 
on a random access file probably does it depending on the OS and type of 
drive, but it isn't creating one in my situation.


When run on Ubuntu, creating the test file is done practically instantly 
whereas it takes 60 seconds on my Windows machine. Downloading takes 
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.


I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file", "createnew", 
hugeFile.getAbsolutePath(),
String.valueOf( HUGE_FILE_SIZE ) 
).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile( hugeFile.getPath(), 
"rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

This matches with the timings I get on Ubuntu (both for the creation of 
the file, and the downloading via Wagon). I ran the build several times 
with this change without any timeout issues. Can you test this change on 
your side?


Side-note: I added "ra.close();" in the code above, because the random 
access file wasn't closed otherwise, and then the file wasn't getting 
deleted properly.


Guillaume

Le 29/12/2016 à 15:50, Michael Osipov a écrit :

Am 2016-12-29 um 12:24 schrieb Guillaume Boué:

I ran them at least 10 times, and there was the timeout issue each time.
Yes, the timeout is Surefire waiting for the forked VM. I applied the
patch (I had done similar tries also) but I still have the issue on
Windows 10.

You'll find the logs attached. It seems that the download is really
advancing (inside target, I can see the file hugetxt slowly
growing), but is just taking a long time. Additionally, the test class
HugeFileDownloadTest is composed of 2 tests, downloading the same file 2
times with different parameters: from the logs, it seems one of them is
succeeding (taking 140 seconds of the 400 in total), and then it times
out performing the second.

Also, part of the issue is probably with the time it takes to create the
4 Go test file that is later downloaded through Wagon (maybe it should
be done by calling the fsutil command when the test runs on Windows).
I'll try to do more timings when running the tests with Ubuntu and see
where the difference is.


Thanks for the analysis. I think the cheapest improvement we can do is 
to create the file only once (setUp(), tearDown(). It is created for 
each test again. I do not think that this is really necessary.


What type of disks do you have? This test passes on my machine within 
70 seconds on a Samsung SSD.


I will apply the patch to the branch because those fixes are necessary 
anyway.


Please keep me updated.

Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Hervé BOUTEMY]

perhaps maven-resolver will require same reset

and we'll need to define which convention to use on Jira when merging code: 
remove "Fix Version: 3.4.0" for example, to track what features have not been 
merged yet

Regards,

Hervé

Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
> On ASF infra, our master branch is supposed to be a protected branch and
> thus cannot be reset or force-pushed without an INFRA ticket.
> 
> If we want to reset our master branch in order to clean out the history of
> the many changes and reverts to and fro etc, we thus need an INFRA ticket
> raised.
> 
> INFRA should not act on such a ticket without the results of a vote of the
> committers that has at least three binding votes from the PMC (i.e. the
> majority of votes cast must be in favour and at least three PMC members
> must have voted in favour)
> 
> Votes are a great way to *confirm* consensus, but a horrible way to build a
> community or establish consensus. We should only ever have a vote thread
> once the consensus seems to be established.
> 
> To establish consensus we use a discuss thread.
> 
> Please refrain from assigning blame, we want to grow our community not
> shrink it. The shorty endorphin rush you get from assigning blame or
> performing The Dance Of I Told You So™ will require repeated hits to
> maintain which will only lead to a more toxic community.
> 
> We have not been good at maintaining our CI infrastructure:
> 
> * As a consequence, some people have been developing on master rather than
> on branches in order to ensure that their development gets the benefit of
> the integration tests
> 
> * This has lead to a lot of micro commits and effectively revert commits on
> master making it hard to track what actually has changed and what has
> actually been fixed.
> 
> * Additionally `git blame` probably now could end up confusing people
> trying to understand the rationale for some changes
> 
> We have not been good at maintaining our Integration tests:
> 
> * As a consequence it has been hard to get our CI infrastructure working
> effectively
> 
> * As a consequence, people have been forced to leverage a single branch for
> CI testing
> 
> We have not been good at developing bigger changes in a branch
> 
> etc.
> 
> I could go on.
> 
> My belief is that confidence in 3.4.0 has been eroded.
> 
> I propose that we reset master back
> to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
> master for the integration tests, and then immediately commit a dummy
> commit so that nobody accidentally does a fast-forward push.
> 
> Then we can cherry pick the changes that were on the old master that we
> want to have in 3.4.0
> 
> This will probably also involve:
> 
> * Fixing the CI infrastructure (I favour using a pipeline multibranch
> project so that branch development is easier,
> https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
> trying to prototype this... currently failing because "windows")
> 
> * Switching to a culture of branch / PR development for all committers
> 
> * Better providing rationale for changes, e.g. we need a succinct
> description of the actual regression between 2.x and 3.x in resolution of
> dependencies of plugins as well as actual easy to understand tests that
> demonstrate the behaviour *and* show that it is an actual regression
> 
> * etc
> 
> But the first step in that would be to reset master...
> 
> So...
> 
> Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?
> 
> What is the correct hash for the integration tests?
> 
> Do we want to do this?
> 
> What else should we change about our processes to prevent the need to do
> this again?
> 
> Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
> that this was a reboot version and any 3.4.x stuff is thus easy to detect
> and filter?
> 
> Save your +1/-1's for actual vote threads, we need to establish a consensus
> first... then in a couple of days, if it looks like we have a consensus I
> will call a vote.
> 
> -Stephen



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Hervé BOUTEMY]

I'm not against putting Jenkins config is source control: this will improve 
tracability.
But until now, the PMC chair is supposed to be able to give karma [1]: this 
should be faster and IMHO remains useful.

If this does not work, an INFRA ticket should be opened

Regards,

Hervé

[1] 
https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount

Le jeudi 29 décembre 2016, 16:20:14 CET Stephen Connolly a écrit :
> Well Jenkins is my day job
> 
> I have no issues seeking time to implement pipeline for Maven as that can
> be seen as benefiting the Jenkins OSS community as well as proving out
> pipeline for real world use cases.
> 
> Note the above is all pure OSS work not the for-pay side of my employers
> house.
> 
> So I am expecting to be able to put some time into improving the CI usage
> of Maven
> 
> If we go the multibranch route then basically once you create the branch in
> git you will get a branch specific job that build each commit until you
> remove the branch. No CI permission required. Most job configuration can be
> handled from the Jenkinsfile which is in git also.
> 
> But the bigger questions we need to resolve first are the *what*
> questions... once we have those sorted the *how* questions will follow.
> Right now we need to get back releasing stuff or we are a dead project
> 
> On Thu 29 Dec 2016 at 15:04, Michael Osipov  wrote:
> > Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
> > > On ASF infra, our master branch is supposed to be a protected branch and
> > > 
> > > thus cannot be reset or force-pushed without an INFRA ticket.
> > > 
> > > 
> > > 
> > > If we want to reset our master branch in order to clean out the history
> > 
> > of
> > 
> > > the many changes and reverts to and fro etc, we thus need an INFRA
> > > ticket
> > > 
> > > raised.
> > > 
> > > 
> > > 
> > > INFRA should not act on such a ticket without the results of a vote of
> > 
> > the
> > 
> > > committers that has at least three binding votes from the PMC (i.e. the
> > > 
> > > majority of votes cast must be in favour and at least three PMC members
> > > 
> > > must have voted in favour)
> > > 
> > > 
> > > 
> > > Votes are a great way to *confirm* consensus, but a horrible way to
> > 
> > build a
> > 
> > > community or establish consensus. We should only ever have a vote thread
> > > 
> > > once the consensus seems to be established.
> > > 
> > > 
> > > 
> > > To establish consensus we use a discuss thread.
> > > 
> > > 
> > > 
> > > Please refrain from assigning blame, we want to grow our community not
> > > 
> > > shrink it. The shorty endorphin rush you get from assigning blame or
> > > 
> > > performing The Dance Of I Told You So™ will require repeated hits to
> > > 
> > > maintain which will only lead to a more toxic community.
> > > 
> > > 
> > > 
> > > We have not been good at maintaining our CI infrastructure:
> > > 
> > > 
> > > 
> > > * As a consequence, some people have been developing on master rather
> > 
> > than
> > 
> > > on branches in order to ensure that their development gets the benefit
> > > of
> > > 
> > > the integration tests
> > > 
> > > 
> > > 
> > > * This has lead to a lot of micro commits and effectively revert commits
> > 
> > on
> > 
> > > master making it hard to track what actually has changed and what has
> > > 
> > > actually been fixed.
> > > 
> > > 
> > > 
> > > * Additionally `git blame` probably now could end up confusing people
> > > 
> > > trying to understand the rationale for some changes
> > > 
> > > 
> > > 
> > > We have not been good at maintaining our Integration tests:
> > > 
> > > 
> > > 
> > > * As a consequence it has been hard to get our CI infrastructure working
> > > 
> > > effectively
> > > 
> > > 
> > > 
> > > * As a consequence, people have been forced to leverage a single branch
> > 
> > for
> > 
> > > CI testing
> > > 
> > > 
> > > 
> > > We have not been good at developing bigger changes in a branch
> > > 
> > > 
> > > 
> > > etc.
> > > 
> > > 
> > > 
> > > I could go on.
> > > 
> > > 
> > > 
> > > My belief is that confidence in 3.4.0 has been eroded.
> > > 
> > > 
> > > 
> > > I propose that we reset master back
> > > 
> > > to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
> > > 
> > > master for the integration tests, and then immediately commit a dummy
> > > 
> > > commit so that nobody accidentally does a fast-forward push.
> > > 
> > > 
> > > 
> > > Then we can cherry pick the changes that were on the old master that we
> > > 
> > > want to have in 3.4.0
> > > 
> > > 
> > > 
> > > This will probably also involve:
> > > 
> > > 
> > > 
> > > * Fixing the CI infrastructure (I favour using a pipeline multibranch
> > > 
> > > project so that branch development is easier,
> > > 
> > > https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
> > > 
> > > trying to prototype this... currently failing because "windows")
> > > 
> > > 
> > > 
> > > * Switching to a 

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Stephen Connolly]

Well Jenkins is my day job

I have no issues seeking time to implement pipeline for Maven as that can
be seen as benefiting the Jenkins OSS community as well as proving out
pipeline for real world use cases.

Note the above is all pure OSS work not the for-pay side of my employers
house.

So I am expecting to be able to put some time into improving the CI usage
of Maven

If we go the multibranch route then basically once you create the branch in
git you will get a branch specific job that build each commit until you
remove the branch. No CI permission required. Most job configuration can be
handled from the Jenkinsfile which is in git also.

But the bigger questions we need to resolve first are the *what*
questions... once we have those sorted the *how* questions will follow.
Right now we need to get back releasing stuff or we are a dead project

On Thu 29 Dec 2016 at 15:04, Michael Osipov  wrote:

> Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
>
> > On ASF infra, our master branch is supposed to be a protected branch and
>
> > thus cannot be reset or force-pushed without an INFRA ticket.
>
> >
>
> > If we want to reset our master branch in order to clean out the history
> of
>
> > the many changes and reverts to and fro etc, we thus need an INFRA ticket
>
> > raised.
>
> >
>
> > INFRA should not act on such a ticket without the results of a vote of
> the
>
> > committers that has at least three binding votes from the PMC (i.e. the
>
> > majority of votes cast must be in favour and at least three PMC members
>
> > must have voted in favour)
>
> >
>
> > Votes are a great way to *confirm* consensus, but a horrible way to
> build a
>
> > community or establish consensus. We should only ever have a vote thread
>
> > once the consensus seems to be established.
>
> >
>
> > To establish consensus we use a discuss thread.
>
> >
>
> > Please refrain from assigning blame, we want to grow our community not
>
> > shrink it. The shorty endorphin rush you get from assigning blame or
>
> > performing The Dance Of I Told You So™ will require repeated hits to
>
> > maintain which will only lead to a more toxic community.
>
> >
>
> > We have not been good at maintaining our CI infrastructure:
>
> >
>
> > * As a consequence, some people have been developing on master rather
> than
>
> > on branches in order to ensure that their development gets the benefit of
>
> > the integration tests
>
> >
>
> > * This has lead to a lot of micro commits and effectively revert commits
> on
>
> > master making it hard to track what actually has changed and what has
>
> > actually been fixed.
>
> >
>
> > * Additionally `git blame` probably now could end up confusing people
>
> > trying to understand the rationale for some changes
>
> >
>
> > We have not been good at maintaining our Integration tests:
>
> >
>
> > * As a consequence it has been hard to get our CI infrastructure working
>
> > effectively
>
> >
>
> > * As a consequence, people have been forced to leverage a single branch
> for
>
> > CI testing
>
> >
>
> > We have not been good at developing bigger changes in a branch
>
> >
>
> > etc.
>
> >
>
> > I could go on.
>
> >
>
> > My belief is that confidence in 3.4.0 has been eroded.
>
> >
>
> > I propose that we reset master back
>
> > to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
>
> > master for the integration tests, and then immediately commit a dummy
>
> > commit so that nobody accidentally does a fast-forward push.
>
> >
>
> > Then we can cherry pick the changes that were on the old master that we
>
> > want to have in 3.4.0
>
> >
>
> > This will probably also involve:
>
> >
>
> > * Fixing the CI infrastructure (I favour using a pipeline multibranch
>
> > project so that branch development is easier,
>
> > https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
>
> > trying to prototype this... currently failing because "windows")
>
> >
>
> > * Switching to a culture of branch / PR development for all committers
>
> >
>
> > * Better providing rationale for changes, e.g. we need a succinct
>
> > description of the actual regression between 2.x and 3.x in resolution of
>
> > dependencies of plugins as well as actual easy to understand tests that
>
> > demonstrate the behaviour *and* show that it is an actual regression
>
> >
>
> > * etc
>
> >
>
> > But the first step in that would be to reset master...
>
> >
>
> > So...
>
> >
>
> > Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?
>
> >
>
> > What is the correct hash for the integration tests?
>
> >
>
> > Do we want to do this?
>
> >
>
> > What else should we change about our processes to prevent the need to do
>
> > this again?
>
> >
>
> > Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
>
> > that this was a reboot version and any 3.4.x stuff is thus easy to detect
>
> > and filter?
>
>
>
> While I do agree to reset master on that commit and we do have deficits
>
> 

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Michael Osipov]

Am 2016-12-29 um 12:18 schrieb Stephen Connolly:

On ASF infra, our master branch is supposed to be a protected branch and
thus cannot be reset or force-pushed without an INFRA ticket.

If we want to reset our master branch in order to clean out the history of
the many changes and reverts to and fro etc, we thus need an INFRA ticket
raised.

INFRA should not act on such a ticket without the results of a vote of the
committers that has at least three binding votes from the PMC (i.e. the
majority of votes cast must be in favour and at least three PMC members
must have voted in favour)

Votes are a great way to *confirm* consensus, but a horrible way to build a
community or establish consensus. We should only ever have a vote thread
once the consensus seems to be established.

To establish consensus we use a discuss thread.

Please refrain from assigning blame, we want to grow our community not
shrink it. The shorty endorphin rush you get from assigning blame or
performing The Dance Of I Told You So™ will require repeated hits to
maintain which will only lead to a more toxic community.

We have not been good at maintaining our CI infrastructure:

* As a consequence, some people have been developing on master rather than
on branches in order to ensure that their development gets the benefit of
the integration tests

* This has lead to a lot of micro commits and effectively revert commits on
master making it hard to track what actually has changed and what has
actually been fixed.

* Additionally `git blame` probably now could end up confusing people
trying to understand the rationale for some changes

We have not been good at maintaining our Integration tests:

* As a consequence it has been hard to get our CI infrastructure working
effectively

* As a consequence, people have been forced to leverage a single branch for
CI testing

We have not been good at developing bigger changes in a branch

etc.

I could go on.

My belief is that confidence in 3.4.0 has been eroded.

I propose that we reset master back
to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
master for the integration tests, and then immediately commit a dummy
commit so that nobody accidentally does a fast-forward push.

Then we can cherry pick the changes that were on the old master that we
want to have in 3.4.0

This will probably also involve:

* Fixing the CI infrastructure (I favour using a pipeline multibranch
project so that branch development is easier,
https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
trying to prototype this... currently failing because "windows")

* Switching to a culture of branch / PR development for all committers

* Better providing rationale for changes, e.g. we need a succinct
description of the actual regression between 2.x and 3.x in resolution of
dependencies of plugins as well as actual easy to understand tests that
demonstrate the behaviour *and* show that it is an actual regression

* etc

But the first step in that would be to reset master...

So...

Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?

What is the correct hash for the integration tests?

Do we want to do this?

What else should we change about our processes to prevent the need to do
this again?

Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
that this was a reboot version and any 3.4.x stuff is thus easy to detect
and filter?


While I do agree to reset master on that commit and we do have deficits 
here, there are some open questions:


1. Who and when is going to solve the CI problem? I personally do not 
even have the permission on Jenkins to create a job to test my branch 
stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve 
flexibility.


2. Commit amount:

$ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l
328
How do you want to replay non-breaking commits onto the new master? 
Will you ask every committer to replay their commits?


3.4 is burned soil. Let's skip it.

Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Releasing Wagon 2.11

[Michael Osipov]

Am 2016-12-29 um 12:24 schrieb Guillaume Boué:

I ran them at least 10 times, and there was the timeout issue each time.
Yes, the timeout is Surefire waiting for the forked VM. I applied the
patch (I had done similar tries also) but I still have the issue on
Windows 10.

You'll find the logs attached. It seems that the download is really
advancing (inside target, I can see the file hugetxt slowly
growing), but is just taking a long time. Additionally, the test class
HugeFileDownloadTest is composed of 2 tests, downloading the same file 2
times with different parameters: from the logs, it seems one of them is
succeeding (taking 140 seconds of the 400 in total), and then it times
out performing the second.

Also, part of the issue is probably with the time it takes to create the
4 Go test file that is later downloaded through Wagon (maybe it should
be done by calling the fsutil command when the test runs on Windows).
I'll try to do more timings when running the tests with Ubuntu and see
where the difference is.


Thanks for the analysis. I think the cheapest improvement we can do is 
to create the file only once (setUp(), tearDown(). It is created for 
each test again. I do not think that this is really necessary.


What type of disks do you have? This test passes on my machine within 70 
seconds on a Samsung SSD.


I will apply the patch to the branch because those fixes are necessary 
anyway.


Please keep me updated.

Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Robert Scholte]

thanks Stephen for picking this up.

SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03
* [maven-release-plugin] prepare for next development iteration

Yes, this is the hash I would expect to revert to.
Based on the date I would expect that maven-its should be reset to

SHA-1: 94bd771c88cc96014ca0ddaa07ac6f778b3c7501
* [MNG-5840] Argh! tests added but not added to suite

I like the idea of pushing to 3.5.0 to indicate there was something with  
3.4.x


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?


Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Releasing Wagon 2.11

[Guillaume Boué]

I ran them at least 10 times, and there was the timeout issue each time. 
Yes, the timeout is Surefire waiting for the forked VM. I applied the 
patch (I had done similar tries also) but I still have the issue on 
Windows 10.


You'll find the logs attached. It seems that the download is really 
advancing (inside target, I can see the file hugetxt slowly 
growing), but is just taking a long time. Additionally, the test class 
HugeFileDownloadTest is composed of 2 tests, downloading the same file 2 
times with different parameters: from the logs, it seems one of them is 
succeeding (taking 140 seconds of the 400 in total), and then it times 
out performing the second.


Also, part of the issue is probably with the time it takes to create the 
4 Go test file that is later downloaded through Wagon (maybe it should 
be done by calling the fsutil command when the test runs on Windows). 
I'll try to do more timings when running the tests with Ubuntu and see 
where the difference is.



Le 29/12/2016 à 01:18, Michael Osipov a écrit :

Am 2016-12-28 um 21:34 schrieb Guillaume Boué:

I have the same results as Hervé, both on Windows and Ubuntu. This is
what I have with Maven 3.3.9:

- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
HugeFileDownloadTest (perhaps the timeout should be increased?)


How often did you run the tests to get this result? I tried at least 
20 times or more.

Can you enable the logging I asked Dan for? You might see something else.

By timeout do you mean the timeout Surefire waits for the forked VM?

Can you try the attached patch? I have noticed that in this 
HugeFileDownloadTest the server is never shutdown as well as in other 
cases.


Michael



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
2016-12-29T12:14:53.319 [main] INFO org.eclipse.jetty.server.Server - 
jetty-8.1.22.v20160922
2016-12-29T12:14:53.334 [main] INFO org.eclipse.jetty.server.AbstractConnector 
- Started SelectChannelConnector@0.0.0.0:50893
http://localhost:50893 - Session: Opened  
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.client.protocol.RequestAddCookies - CookieSpec selected: 
compatibility
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection 
request: [route: {}->http://localhost:50893][total kept alive: 38; route 
allocated: 0 of 20; total allocated: 39 of 40]
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection 
leased: [id: 254][route: {}->http://localhost:50893][total kept alive: 38; 
route allocated: 1 of 20; total allocated: 40 of 40]
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Opening connection 
{}->http://localhost:50893
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - Connecting to 
localhost/127.0.0.1:50893
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - Connection 
established 127.0.0.1:50896<->127.0.0.1:50893
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.DefaultManagedHttpClientConnection - 
http-outgoing-254: set socket timeout to 180
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Executing request GET 
/hugefile.txt HTTP/1.1
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Target auth state: UNCHALLENGED
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Proxy auth state: UNCHALLENGED
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> GET /hugefile.txt HTTP/1.1
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Cache-control: no-cache
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Cache-store: no-store
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Pragma: no-cache
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Expires: 0
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Accept-Encoding: gzip
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Host: localhost:50893
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Connection: Keep-Alive
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_102)
2016-12-29T12:14:53.459 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 << HTTP/1.1 200 OK
2016-12-29T12:14:53.459 [main] DEBUG 

[DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Stephen Connolly]

On ASF infra, our master branch is supposed to be a protected branch and
thus cannot be reset or force-pushed without an INFRA ticket.

If we want to reset our master branch in order to clean out the history of
the many changes and reverts to and fro etc, we thus need an INFRA ticket
raised.

INFRA should not act on such a ticket without the results of a vote of the
committers that has at least three binding votes from the PMC (i.e. the
majority of votes cast must be in favour and at least three PMC members
must have voted in favour)

Votes are a great way to *confirm* consensus, but a horrible way to build a
community or establish consensus. We should only ever have a vote thread
once the consensus seems to be established.

To establish consensus we use a discuss thread.

Please refrain from assigning blame, we want to grow our community not
shrink it. The shorty endorphin rush you get from assigning blame or
performing The Dance Of I Told You So™ will require repeated hits to
maintain which will only lead to a more toxic community.

We have not been good at maintaining our CI infrastructure:

* As a consequence, some people have been developing on master rather than
on branches in order to ensure that their development gets the benefit of
the integration tests

* This has lead to a lot of micro commits and effectively revert commits on
master making it hard to track what actually has changed and what has
actually been fixed.

* Additionally `git blame` probably now could end up confusing people
trying to understand the rationale for some changes

We have not been good at maintaining our Integration tests:

* As a consequence it has been hard to get our CI infrastructure working
effectively

* As a consequence, people have been forced to leverage a single branch for
CI testing

We have not been good at developing bigger changes in a branch

etc.

I could go on.

My belief is that confidence in 3.4.0 has been eroded.

I propose that we reset master back
to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
master for the integration tests, and then immediately commit a dummy
commit so that nobody accidentally does a fast-forward push.

Then we can cherry pick the changes that were on the old master that we
want to have in 3.4.0

This will probably also involve:

* Fixing the CI infrastructure (I favour using a pipeline multibranch
project so that branch development is easier,
https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
trying to prototype this... currently failing because "windows")

* Switching to a culture of branch / PR development for all committers

* Better providing rationale for changes, e.g. we need a succinct
description of the actual regression between 2.x and 3.x in resolution of
dependencies of plugins as well as actual easy to understand tests that
demonstrate the behaviour *and* show that it is an actual regression

* etc

But the first step in that would be to reset master...

So...

Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?

What is the correct hash for the integration tests?

Do we want to do this?

What else should we change about our processes to prevent the need to do
this again?

Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
that this was a reboot version and any 3.4.x stuff is thus easy to detect
and filter?

Save your +1/-1's for actual vote threads, we need to establish a consensus
first... then in a couple of days, if it looks like we have a consensus I
will call a vote.

-Stephen

[GitHub] maven-surefire pull request #138: SUREFIRE-1309: Clarifying use of regular e...

[sverhagen]

Github user sverhagen closed the pull request at:

https://github.com/apache/maven-surefire/pull/138


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #138: SUREFIRE-1309: Clarifying use of regular expressi...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/138
  
@sverhagen 
Thx for contributing. This PR was merged. Pls close it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org