subject:"What to do with the 6 issues left as 3.5.0\-candidates\?"

for the sake of completeness, there are 2 issues which have been merged to 
master a few hours after beta-1 vote started, without asking for review:

MNG-6112
MNG-6190

MNG-6190 looks like a stupid bug that was reported just after the vote 
started: looks like a safe option to integrate it, I'm ok on the result (not 
on the way it has been merged)

MNG-6112 is harder to estimate side effects IMHO
and since this has been available for a long time, I'm really not satisfied 
that it has been integrated *after vote for 3.0.5-beta-1 started* (and in 
addition without any discussion)

 I'd say punt to 3.5.1: benefit is not worth the risk for now (we lived for 
years with that, we can stay with it for a couple of months to have wider 
tests)

Regards,

Hervé

Le vendredi 24 mars 2017, 10:45:14 CET Stephen Connolly a écrit :
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVe
> rsion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Here is my opinions:
> 
> https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt to
> 3.5.1
> 
> https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
> ready quickly (i.e. in the next week), we can review the changes and assess
> the risk
> 
> https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged and
> released upstream yet... punt to 3.5.1
> 
> https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt to
> 3.5.1 (anyway I see similar issues with other native tooling that uses
> console colouring)
> 
> https://issues.apache.org/jira/browse/MNG-6169 - definitely too late. punt
> to 3.5.1
> 
> https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a javadoc
> change. If available quickly should be ok
> 
> If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
> 3.5.0 and the rest to 3.5.1-candidates



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

Re: What to do with the 6 issues left as 3.5.0-candidates?

I'd prefer to avoid all the "final" modifiers appearing from time to time: our 
convention is not to use final modifier

Regards,

Hervé

Le vendredi 24 mars 2017, 22:07:34 CET Christian Schulte a écrit :
> Am 03/24/17 um 11:45 schrieb Stephen Connolly:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fix
> > Version%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20OR
> > DER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > 
> > Here is my opinions:
> > 
> > https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
> > ready quickly (i.e. in the next week), we can review the changes and
> > assess
> > the risk
> 
> Branch is here:
>  /MNG-6168>
> 
> Commit is here:
>  c7630cc79adb98407db13315b4a709ee>
> 
> Will merge to master, as soon as the build job succeeds. It's just
> updates to use the try-with-resources statement instead of
> try-catch-finally with IOUtil.close.
> 
> Regards,



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

Re: What to do with the 6 issues left as 3.5.0-candidates?

or we need testers interested in working on it, testing, reporting: not 
everything will come from infra (& associated bucks) but from community

Regards,

Hervé

Le samedi 25 mars 2017, 01:41:03 CET Christian Schulte a écrit :
> We really need Solaris and OSX Jenkins build nodes :-)
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: What to do with the 6 issues left as 3.5.0-candidates?

Le vendredi 24 mars 2017, 15:35:50 CET Robert Scholte a écrit :
> On Fri, 24 Mar 2017 14:51:22 +0100, Stephen Connolly
> 
>  wrote:
> > On 24 March 2017 at 10:51, Robert Scholte  wrote:
> >> On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >> 
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> >> 
> >>> 20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20r
> >>> esolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%
> >>> 20priority%20DESC%2C%20created%20ASC
> >>> 
> >>> Here is my opinions:
> >>> 
> >>> https://issues.apache.org/jira/browse/MNG-6167 - it's too late now.
> >>> punt
> >>> to
> >>> 3.5.1
> >>> 
> >>> https://issues.apache.org/jira/browse/MNG-6168 - If this is available
> >>> and
> >>> ready quickly (i.e. in the next week), we can review the changes and
> >>> assess
> >>> the risk
> >>> 
> >>> https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
> >>> and
> >>> released upstream yet... punt to 3.5.1
> >>> 
> >>> https://issues.apache.org/jira/browse/MNG-6188 - it's too late now.
> >>> punt
> >>> to
> >>> 3.5.1 (anyway I see similar issues with other native tooling that uses
> >>> console colouring)
> >>> 
> >>> https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
> >>> punt
> >>> to 3.5.1
> >>> 
> >>> https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
> >>> javadoc
> >>> change. If available quickly should be ok
> >>> 
> >>> If there is agreement then I will move MNG-6185 and MNG-6168 into fix
> >>> for
> >>> 3.5.0 and the rest to 3.5.1-candidates
> >> 
> >> I agree on MNG-6185 and MNG-6168.
> >> 
> >> IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with
> >> our
> >> own proposed patch. If users see that their diskspace is decreasing and
> >> discover that the lib/ext if full of temporary files, they have a fair
> >> point to complain.
> > 
> > I think the remaining bit open there is to remove the duplicate code once
> > upstream has the required functionality. the disk space issue has been
> > fixed IIUC
> 
> Confirmed, I see apache-maven-3.5.0-beta-1/lib/jansi-native.
yes, this was MNG-6115 fix (done with some HawtJNI copy/paste inside :) )

> In that case let's push this one to 3.5.1
+1 that's my intent

> 
> >> All others can be pushed to 3.5.1
+1

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



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

Re: What to do with the 6 issues left as 3.5.0-candidates?

We really need Solaris and OSX Jenkins build nodes :-)


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

Am 03/25/17 um 01:30 schrieb Christian Schulte:
> Am 03/24/17 um 23:28 schrieb Stephen Connolly:
>> Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
>> ) is not available
> 
> Thanks for pointing this out. Our launchers have this in the first line:
> 
> #!/bin/sh
> 
> /bin/sh should be a POSIX compatible shell. On the BSDs, OSX and Solaris
> (IIRC) this is some kind of ksh. The man page on OpenBSD explicitly
> states this:
> 
> This version of sh is actually ksh in disguise. As such, it also
> supports the features described in ksh(1). This manual page describes
> only the parts relevant to a POSIX compliant sh. If portability is a
> concern, use only those features described in this page.
> 
> They provide different man pages for sh and ksh although /bin/sh is ksh.
> 
> http://man.openbsd.org/sh
> http://man.openbsd.org/ksh
> 
> Can you provide a link to some BourneShell man page (a real one, not
> bash)? We should fix the launchers in 3.5.0 once and for all.
> 
> Currently reading the "Shell & Utilities" volume from here:
> 
> 
> 
> This is what we should be compatible to. Did not find anything about
> "readlink" in there so we should not be using it and find a compliant
> solution.
> 
> Regards,
> 

Seems we really should be using "`pwd -P`" as you suggested.




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

Re: What to do with the 6 issues left as 3.5.0-candidates?

Am 03/24/17 um 23:28 schrieb Stephen Connolly:
> Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
> ) is not available

Thanks for pointing this out. Our launchers have this in the first line:

#!/bin/sh

/bin/sh should be a POSIX compatible shell. On the BSDs, OSX and Solaris
(IIRC) this is some kind of ksh. The man page on OpenBSD explicitly
states this:

This version of sh is actually ksh in disguise. As such, it also
supports the features described in ksh(1). This manual page describes
only the parts relevant to a POSIX compliant sh. If portability is a
concern, use only those features described in this page.

They provide different man pages for sh and ksh although /bin/sh is ksh.

http://man.openbsd.org/sh
http://man.openbsd.org/ksh

Can you provide a link to some BourneShell man page (a real one, not
bash)? We should fix the launchers in 3.5.0 once and for all.

Currently reading the "Shell & Utilities" volume from here:



This is what we should be compatible to. Did not find anything about
"readlink" in there so we should not be using it and find a compliant
solution.

Regards,
-- 
Christian


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
) is not available

On Fri 24 Mar 2017 at 22:15, Christian Schulte  wrote:

> Am 03/24/17 um 22:51 schrieb Stephen Connolly:
> > I am concerned that there are some quoting issues in mvn.
> >
> > In some cases we use var=`command` and in others we use var="`command`"
> >
> > Additionally we have a mixture of backtick and $(...) style. My
> > understanding is that the backticks are for older shells...
> > but if that is the case we should use backticks consistently
> >
> > line 64: saveddir=`pwd`
> > should be? saveddir="`pwd`"
> >
> > line 66: MAVEN_HOME=`dirname "$PRG"`/..
> > should be? MAVEN_HOME="`dirname "$PRG"`/.."
> >
> > line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
> > should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"
> >
> > line 105: CLASSWORLDS_JAR=`echo
> > "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
> > should be? CLASSWORLDS_JAR="`echo
> > "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"
> >
> > line 128:  basedir=$wdir
> > should be?  basedir="$wdir"
> >
> > line 145: basedir=$(dirname "$(readlink -f "${arg}")")
> > should be? basedir="$(dirname "$(readlink -f "${arg}")")"
> > (or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"
> >
> > line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
> > "$MAVEN_PROJECTBASEDIR"`
> > should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
> > "$MAVEN_PROJECTBASEDIR"`"
> >
> > /me got tired looking at the file after this point in time!
> >
>
> According to the "Expansion" section from the sh man page
> () the double quotes should be there to
> disable field splitting.
>
> [...]
> Command expansion has a command executed in a subshell and the results
> output in its place.  The basic format is:
>
> $(command)
>
>   or
>
> `command`
>
> The results are subject to field splitting and pathname expansion; no
> other form of expansion happens.  If command is contained within double
> quotes, field splitting does not happen either.  Within backquotes, a
> backslash is treated literally unless it follows a dollar sign,
> backquote, or another backslash.  Commands can be nested, though the
> backquoted version requires backslashes before the backquotes. If
> command is run in a subshell in the bracketed version, the syntax is
> identical to that of arithmetic expansion. In that case the shell
> attempts arithmetic expansion first, then attempts command substitution
> if that fails.  Or a non-ambiguous version can be used:
>
> $( (command) )
>
> Arithmetic expansion works similarly, with an arithmetic expression
> being evaluated and substituted. The format is:
>
> $((expression))
>
> Where expression is an integer, parameter name, or array reference,
> optionally combined with any of the operators described below, listed
> and grouped according to precedence:
> [...]
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: What to do with the 6 issues left as 3.5.0-candidates?

Am 03/24/17 um 22:51 schrieb Stephen Connolly:
> I am concerned that there are some quoting issues in mvn.
> 
> In some cases we use var=`command` and in others we use var="`command`"
> 
> Additionally we have a mixture of backtick and $(...) style. My
> understanding is that the backticks are for older shells...
> but if that is the case we should use backticks consistently
> 
> line 64: saveddir=`pwd`
> should be? saveddir="`pwd`"
> 
> line 66: MAVEN_HOME=`dirname "$PRG"`/..
> should be? MAVEN_HOME="`dirname "$PRG"`/.."
> 
> line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
> should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"
> 
> line 105: CLASSWORLDS_JAR=`echo
> "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
> should be? CLASSWORLDS_JAR="`echo
> "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"
> 
> line 128:  basedir=$wdir
> should be?  basedir="$wdir"
> 
> line 145: basedir=$(dirname "$(readlink -f "${arg}")")
> should be? basedir="$(dirname "$(readlink -f "${arg}")")"
> (or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"
> 
> line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
> "$MAVEN_PROJECTBASEDIR"`
> should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
> "$MAVEN_PROJECTBASEDIR"`"
> 
> /me got tired looking at the file after this point in time!
>

According to the "Expansion" section from the sh man page
() the double quotes should be there to
disable field splitting.

[...]
Command expansion has a command executed in a subshell and the results
output in its place.  The basic format is:

$(command)

  or

`command`

The results are subject to field splitting and pathname expansion; no
other form of expansion happens.  If command is contained within double
quotes, field splitting does not happen either.  Within backquotes, a
backslash is treated literally unless it follows a dollar sign,
backquote, or another backslash.  Commands can be nested, though the
backquoted version requires backslashes before the backquotes. If
command is run in a subshell in the bracketed version, the syntax is
identical to that of arithmetic expansion. In that case the shell
attempts arithmetic expansion first, then attempts command substitution
if that fails.  Or a non-ambiguous version can be used:

$( (command) )

Arithmetic expansion works similarly, with an arithmetic expression
being evaluated and substituted. The format is:

$((expression))

Where expression is an integer, parameter name, or array reference,
optionally combined with any of the operators described below, listed
and grouped according to precedence:
[...]

Regards,
-- 
Christian


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

I am concerned that there are some quoting issues in mvn.

In some cases we use var=`command` and in others we use var="`command`"

Additionally we have a mixture of backtick and $(...) style. My
understanding is that the backticks are for older shells...
but if that is the case we should use backticks consistently

line 64: saveddir=`pwd`
should be? saveddir="`pwd`"

line 66: MAVEN_HOME=`dirname "$PRG"`/..
should be? MAVEN_HOME="`dirname "$PRG"`/.."

line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"

line 105: CLASSWORLDS_JAR=`echo
"${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
should be? CLASSWORLDS_JAR="`echo
"${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"

line 128:  basedir=$wdir
should be?  basedir="$wdir"

line 145: basedir=$(dirname "$(readlink -f "${arg}")")
should be? basedir="$(dirname "$(readlink -f "${arg}")")"
(or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"

line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
"$MAVEN_PROJECTBASEDIR"`
should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
"$MAVEN_PROJECTBASEDIR"`"

/me got tired looking at the file after this point in time!

On 24 March 2017 at 21:07, Christian Schulte  wrote:

> Am 03/24/17 um 11:45 schrieb Stephen Connolly:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%
> 20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> 20DESC%2C%20created%20ASC
> >
> > Here is my opinions:
> >
> > https://issues.apache.org/jira/browse/MNG-6168 - If this is available
> and
> > ready quickly (i.e. in the next week), we can review the changes and
> assess
> > the risk
>
> Branch is here:
>  shortlog;h=refs/heads/MNG-6168>
>
> Commit is here:
>  0931bb2cc7630cc79adb98407db13315b4a709ee>
>
> Will merge to master, as soon as the build job succeeds. It's just
> updates to use the try-with-resources statement instead of
> try-catch-finally with IOUtil.close.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What to do with the 6 issues left as 3.5.0-candidates?

Am 03/24/17 um 11:45 schrieb Stephen Connolly:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Here is my opinions:
> 
> https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
> ready quickly (i.e. in the next week), we can review the changes and assess
> the risk

Branch is here:


Commit is here:


Will merge to master, as soon as the build job succeeds. It's just
updates to use the try-with-resources statement instead of
try-catch-finally with IOUtil.close.

Regards,
-- 
Christian


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Robert Scholte

On Fri, 24 Mar 2017 14:51:22 +0100, Stephen Connolly  
 wrote:



On 24 March 2017 at 10:51, Robert Scholte  wrote:


On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

https://issues.apache.org/jira/issues/?jql=project%20%3D%

20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20r
esolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%
20priority%20DESC%2C%20created%20ASC

Here is my opinions:

https://issues.apache.org/jira/browse/MNG-6167 - it's too late now.  
punt

to
3.5.1

https://issues.apache.org/jira/browse/MNG-6168 - If this is available  
and

ready quickly (i.e. in the next week), we can review the changes and
assess
the risk

https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
and
released upstream yet... punt to 3.5.1

https://issues.apache.org/jira/browse/MNG-6188 - it's too late now.  
punt

to
3.5.1 (anyway I see similar issues with other native tooling that uses
console colouring)

https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
punt
to 3.5.1

https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
javadoc
change. If available quickly should be ok

If there is agreement then I will move MNG-6185 and MNG-6168 into fix  
for

3.5.0 and the rest to 3.5.1-candidates



I agree on MNG-6185 and MNG-6168.

IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with  
our

own proposed patch. If users see that their diskspace is decreasing and
discover that the lib/ext if full of temporary files, they have a fair
point to complain.



I think the remaining bit open there is to remove the duplicate code once
upstream has the required functionality. the disk space issue has been
fixed IIUC



Confirmed, I see apache-maven-3.5.0-beta-1/lib/jansi-native.
In that case let's push this one to 3.5.1





All others can be pushed to 3.5.1

Robert

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



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

Re: What to do with the 6 issues left as 3.5.0-candidates?

On 24 March 2017 at 10:51, Robert Scholte  wrote:

> On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20r
>> esolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%
>> 20priority%20DESC%2C%20created%20ASC
>>
>> Here is my opinions:
>>
>> https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt
>> to
>> 3.5.1
>>
>> https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
>> ready quickly (i.e. in the next week), we can review the changes and
>> assess
>> the risk
>>
>> https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
>> and
>> released upstream yet... punt to 3.5.1
>>
>> https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt
>> to
>> 3.5.1 (anyway I see similar issues with other native tooling that uses
>> console colouring)
>>
>> https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
>> punt
>> to 3.5.1
>>
>> https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
>> javadoc
>> change. If available quickly should be ok
>>
>> If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
>> 3.5.0 and the rest to 3.5.1-candidates
>>
>
> I agree on MNG-6185 and MNG-6168.
>
> IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with our
> own proposed patch. If users see that their diskspace is decreasing and
> discover that the lib/ext if full of temporary files, they have a fair
> point to complain.
>

I think the remaining bit open there is to remove the duplicate code once
upstream has the required functionality. the disk space issue has been
fixed IIUC


>
> All others can be pushed to 3.5.1
>
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Robert Scholte

On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly
wrote:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Here is my opinions:

https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt
to

3.5.1

https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
ready quickly (i.e. in the next week), we can review the changes and
assess

the risk

https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
and

released upstream yet... punt to 3.5.1

https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt
to

3.5.1 (anyway I see similar issues with other native tooling that uses
console colouring)

https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
punt

to 3.5.1

https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
javadoc

change. If available quickly should be ok

If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
3.5.0 and the rest to 3.5.1-candidates

I agree on MNG-6185 and MNG-6168.

IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with our
own proposed patch. If users see that their diskspace is decreasing and
discover that the lib/ext if full of temporary files, they have a fair
point to complain.

All others can be pushed to 3.5.1

Robert

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

What to do with the 6 issues left as 3.5.0-candidates?