[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[arunvinudss]

Github user arunvinudss commented on the issue:

https://github.com/apache/commons-text/pull/49
  
Ordering of import has changed as all the similar packages were grouped 
together. It was not intended I believe my IDE did that automatically. I see 
other test classes using wild card imports too not sure we have a standard for 
that.


---
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...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] Preparing for Release; Questions

[Gary Gregory]

Are they in sync now? Make sure you have you Maven settings set up just so.
I think Maven has some docs on how to encrypted and save your passwords.

Gary

On Mon, Jul 10, 2017 at 8:57 PM, Carl Hall  wrote:

> Hey Gary,
>
> Thanks for adding me, but I'm getting the same error message as before.  I
> checked my profile in whimsy and I appear to be a committer on commons and
> part of the "committers" group.
> It might be completely unrelated, but Github and git.a.o aren't in sync
> with git-wip-us.a.o.  Maybe some weirdo setup thing somewhere?
>
> On Sun, Jul 9, 2017 at 2:48 PM, Gary Gregory 
> wrote:
>
> > Hi Carl,
> >
> > As you already are an Apache Committer, I've added you to the Commons
> > Committers group, please try again in a few minutes.
> >
> > Gary
> >
> > On Sun, Jul 9, 2017 at 2:08 PM, Carl Hall  wrote:
> >
> > > Hi all,
> > >
> > > I'd like to make a release of dbutils.  I've worked through the release
> > > preparation guide[1] up to deploying the RC.  Rather expectedly, since
> > this
> > > is my first attempt at releasing, I'm not able to complete the `mvn
> > deploy`
> > > step.
> > >
> > > ```
> > > Failed to transfer file:
> > > https://repository.apache.org/service/local/staging/deploy/
> > > maven2/commons-dbutils/commons-dbutils/1.7/commons-dbutils-1.7.jar.
> > > Return code is: 401, ReasonPhrase: Unauthorized.
> > > ```
> > >
> > > Should I ask for write permission or should I ask someone else to
> manage
> > > the release?
> > >
> > > Thanks,
> > > Carl
> > >
> > > 1 https://commons.apache.org/releases/prepare.html
> > >
> >
>

Re: [daemon] moving to git ? and bump java version.

[Gary Gregory]

As far as migrating from svn to git, it's just busy work an Apache
Committers needs to volunteer to do. Certainly not critical, especially
since this component does not get much attention these days.

Gary

On Tue, Jul 11, 2017 at 12:02 PM, Amey Jadiye  wrote:

> Hi Daemon Maintainers / All,
>
> Daemon seems to be still being maintained on svn, do we have any plan
> moving code base to git ?
>
> As fact there is low activity in daemon no one thought of bumping version
> from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
> shall we bump it minimum to 1.6 ?
>
> Regards,
> Amey
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[jbduncan]

Github user jbduncan commented on the issue:

https://github.com/apache/commons-text/pull/49
  
It's not clear to me why the ordering of the imports has changed and why 
all the `assert*()` method imports have been replaced with a wildcard import. 
Are those intentional?


---
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...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [daemon] moving to git ? and bump java version.

[Gary Gregory]

The only reason to update to Java 6 is that Java 9 will no longer compiler
for targets below Java 6, which is fine with me. Java 7 would also be OK by
me.

Gary

On Tue, Jul 11, 2017 at 12:02 PM, Amey Jadiye  wrote:

> Hi Daemon Maintainers / All,
>
> Daemon seems to be still being maintained on svn, do we have any plan
> moving code base to git ?
>
> As fact there is low activity in daemon no one thought of bumping version
> from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
> shall we bump it minimum to 1.6 ?
>
> Regards,
> Amey
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[ecki]

Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
It still uses missleading UTF-32


---
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...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [daemon] moving to git ? and bump java version.

[Matt Sicker]

We could migrate to git as we've been slowly doing for most of Commons.
Someone needs to take charge and handle it, though. A lazy vote thread to
do so is the usual way to start the process.

On 11 July 2017 at 14:02, Amey Jadiye  wrote:

> Hi Daemon Maintainers / All,
>
> Daemon seems to be still being maintained on svn, do we have any plan
> moving code base to git ?
>
> As fact there is low activity in daemon no one thought of bumping version
> from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
> shall we bump it minimum to 1.6 ?
>
> Regards,
> Amey
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Matt Sicker 

[daemon] moving to git ? and bump java version.

[Amey Jadiye]

Hi Daemon Maintainers / All,

Daemon seems to be still being maintained on svn, do we have any plan
moving code base to git ?

As fact there is low activity in daemon no one thought of bumping version
from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
shall we bump it minimum to 1.6 ?

Regards,
Amey

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

[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/49
  
@chtompki , this PR looks good, shall we merge 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...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[daemon] Enhance README.md for github

[Amey Jadiye]

Hi All,

Since Commons Daemon lacks the detail description on README file I'd like
to take that task up also I think it needs some nice new shiny emblems
showing status of project like sample I have given below from commons-text.

[![Build Status](
https://travis-ci.org/apache/commons-text.svg?branch=master)](https://travis-ci.org/apache/commons-text
)
[![Coverage Status](
https://coveralls.io/repos/apache/commons-text/badge.svg?branch=master)](https://coveralls.io/r/apache/commons-text
)
[![Maven Central](
https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-text/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-text/
)


Travis is configured, so getting build info is easy. (
https://api.travis-ci.org/apache/commons-daemon.svg?branch=trunk)
Also putting the badge from maven central will look good. (
https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-daemon/badge.svg)


Not sure I have access to configure coverall so can someone please
configure it for me ? or let me know instructions that would be enough.

Regards,
Amey

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

Re: [daemon] : fixing some general stuff

[Amey Jadiye]

Hi All,

Its was quite tedious task but I have fixed almost all errors from the
commons daemon from maven perspective and below default goals running
clean, I would appreciate if someone take look at PR.
https://github.com/apache/commons-daemon/pull/3

mvn clean verify apache-rat:check clirr:check checkstyle:check
findbugs:check javadoc:javadoc

checkstyle:check  :-  178 Errors, corrected all of them.
javadoc:javadoc   :-   20+ Error, corrected all of them.
apache-rat:check :-  4 Errors, placed file in rat exclusion.
findbugs:check :-  4 Errors, corrected all.
clirr:check :-  This was running good.


for the junit test cases additions will open another jira to track.

Regards,
Amey




On Mon, Jul 10, 2017 at 12:34 AM, Amey Jadiye  wrote:

> Hi Bernd/Mark/All,
>
> I have raised PR to cover this, would you mind just take a look ?
> https://github.com/apache/commons-daemon/pull/3
> So far I have fixed rat, findbug. I will push javadoc and checkstyle
> sometime tomorrow.
>
> Regards,
> Amey
>
> On Sun, Jul 9, 2017 at 9:34 PM, Amey Jadiye  wrote:
>
>> Thanks Bernd,
>>
>> I had plan B for those crying rat, will put those files to exclusion of
>> checking.
>>
>> I can take care of checkstyle, findbug, javadoc.
>>
>> I'm more interested about test cases now. do we have any options around C
>> code coverage with maven [ java code coverage is easy though], OR even is
>> that required?
>>
>> Regards,
>> Amey
>>
>>
>> On Sun, Jul 9, 2017, 9:26 PM Bernd Eckenfels 
>> wrote:
>>
>>> Hello,
>>>
>>> I think the autoconf related files are generated by GNU tools and cannot
>>> be re-licensed. They are not in the binary packages but they do contaminate
>>> the source archives. It is not yet mentioned in the NOTICE file but I guess
>>> there is a ASF wide regulation for those build scripts. Does anybody know?
>>>
>>> Thanks for looking at the issues, would be good if you commit smaller
>>> batches more often, since there is generally some more interest in the
>>> project currently. If you want I can help with the Javadoc warnings?
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> 
>>> From: Amey Jadiye 
>>> Sent: Sunday, July 9, 2017 4:00:08 PM
>>> To: Commons Developers List
>>> Subject: [daemon] : fixing some general stuff
>>>
>>> Hi All,
>>>
>>> I'm going through apache daemon code and trying to fix the stuff breaking
>>> with below maven options, also would like to know if some more checks can
>>> be added since this repo contains lot of C code.
>>>
>>> mvn clean verify apache-rat:check clirr:check checkstyle:check
>>> findbugs:check javadoc:javadoc
>>>
>>> couple of things I'd like to discuss and get opinion.
>>>
>>> #1. TESTS: No test cases present, adding some could be a good add [at
>>> least
>>> for java code], not idea about C code.
>>>
>>> #2. RAT : apache-rat is crying for  4 files, it is ok to add APACHE
>>> LICENSE
>>> but I found they already have GPLv3 in them, shall we replace them, or we
>>> need consent ?
>>> src/native/unix/support/config.sub
>>> src/native/unix/support/config.guess
>>> src/native/unix/native/.indent.pro
>>>
>>> #3. CLIRR : building good.
>>>
>>> #4. CHECKSTYLE: Hell lot of mess, 170+ errors, but I can take them down
>>> one
>>> by one, no big deal.
>>>
>>> #5   FINDBUG: 4 bugs, no big deal.
>>>
>>> #6. JAVADOC: Few bugs, again no big deal.
>>>
>>> Regards,
>>> Amey
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>
>
> --
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 

-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Applying IntelliJ IDEA refactorings

[Jonathan Bluett-Duncan]

Thanks Matt and Gary!

I've just made a PR at https://github.com/apache/commons-lang/pull/276.

Jonathan

On 10 July 2017 at 03:47, Gary Gregory  wrote:

> On Jul 9, 2017 18:49, "Matt Sicker"  wrote:
>
> I personally don't see the point of making a jira issue for it.
>
>
> Agreed.
>
> Gary
>
>
> On 9 July 2017 at 20:19, Jonathan Bluett-Duncan 
> wrote:
>
> > Okay, thanks for the clarification Gary.
> >
> > Does this mean, by extension, that there's no need to create a new JIRA
> > issue? In other words, would just a new GitHub PR be fine (at least for
> > now)?
> >
> > Jonathan
> >
> > On 10 July 2017 at 01:32, Gary Gregory  wrote:
> >
> > > I would think an ICLA is not needed if the only thing we are talking
> > about
> > > are clean-up style refactoring.
> > >
> > > Gary
> > >
> > > On Sun, Jul 9, 2017 at 2:27 PM, Jonathan Bluett-Duncan <
> > > jbluettdun...@gmail.com> wrote:
> > >
> > > > I've re-read the contribution guidelines
> > > >  >,
> > > but
> > > > it's not clear to me if my changes are non-trivial enough to warrant
> a
> > > new
> > > > JIRA issue.
> > > >
> > > > Can someone advise me on this?
> > > >
> > > > Jonathan
> > > >
> > > > On 6 July 2017 at 00:51, Jonathan Bluett-Duncan <
> > jbluettdun...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Okay, I don't intend to apply any `@SuppressWarnings` during my
> > > > > refactoring efforts - if IntelliJ still reports warnings after my
> > > > efforts,
> > > > > then I can live with that. :)
> > > > >
> > > > > Jonathan
> > > > >
> > > > > On 6 July 2017 at 00:31, Matt Sicker  wrote:
> > > > >
> > > > >> The only thing I can think of that conflicts sometimes with IDEA
> > > versus
> > > > >> Eclipse are custom @SupressWarnings strings causing warnings in
> > > Eclipse.
> > > > >> The default IntelliJ warnings tend to be simple things that
> wouldn't
> > > > cause
> > > > >> an issue, however, based in my experience. It's only some of the
> > > > advanced
> > > > >> inspections that can get strange.
> > > > >>
> > > > >> On 5 July 2017 at 17:24, Jonathan Bluett-Duncan <
> > > > jbluettdun...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Great! Sounds like there's general agreement on me pursuing at
> > least
> > > > >> some
> > > > >> > of these refactorings, right?
> > > > >> >
> > > > >> > On the subject of code style guidelines, AFAIK [lang] uses
> > > Checkstyle
> > > > to
> > > > >> > check style adherence? So I assume that if the corresponding
> Maven
> > > > goal
> > > > >> > passes after a refactoring, then it's okay to submit it as a
> > GitHub
> > > > PR.
> > > > >> >
> > > > >> > I don't expect changes suggested by IDEA to cause
> warnings/errors
> > in
> > > > >> > Eclipse or for the Eclipse Java compiler either. Is there an
> > > automated
> > > > >> way
> > > > >> > to explicitly check for things like this through Apache's
> > > > >> infrastructure?
> > > > >> > Or would I need to manually download Eclipse and check on my
> > > machine?
> > > > >> >
> > > > >> > I've already created an Apache JIRA account and signed the CLA,
> > but
> > > > now
> > > > >> > it's not clear to me what to do next. Can someone kindly advise
> me
> > > on
> > > > >> the
> > > > >> > next step?
> > > > >> >
> > > > >> > Jonathan
> > > > >> >
> > > > >> > On 5 July 2017 at 20:33, Gary Gregory 
> > > wrote:
> > > > >> >
> > > > >> > > Keep in mind that not all of us use IDEA. For example, I am on
> > > > >> Eclipse. I
> > > > >> > > do not think this should be an issue for any of these changes
> > > > thougg.
> > > > >> I
> > > > >> > do
> > > > >> > > not expect that changes from IDEA warnings would cause the
> > Eclipse
> > > > >> Java
> > > > >> > > compiler to issue warnings, and vice-versa.
> > > > >> > >
> > > > >> > > Gary
> > > > >> > >
> > > > >> > > On Jul 5, 2017 12:23, "Allon Mureinik" 
> > > wrote:
> > > > >> > >
> > > > >> > > > I've submitted several such cleanups over the past couple of
> > > > month,
> > > > >> and
> > > > >> > > for
> > > > >> > > > the most part, they've been well received.
> > > > >> > > >
> > > > >> > > > I think the key here is to improve the codebase when
> possible
> > > but
> > > > to
> > > > >> > > leave
> > > > >> > > > room to deviate from IntelliJ's norms when there's a good
> > reason
> > > > to.
> > > > >> > > > Perhaps annotating such places with @SuppressWarning would
> be
> > > the
> > > > >> best
> > > > >> > > > approach, to signal to future developers that the warning
> was
> > > > >> > considered,
> > > > >> > > > and we explicitly decided to suppress it (possibly with a
> > > comment
> > > > in
> > > > >> > the
> > > > >> > > > code explaining why).
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > On Wed, Jul 5, 2017 at 6:42 PM, Matt Sicker <
> boa...@gmail.com
> > >
> 

[RESULT][VOTE][LAZY] Move commons-collections to git.

[Rob Tompkins]

This vote passes with the following votes in order of appearance:

Amey Jadiye: +1
Mark Dacek: +1
Gary Gregory: +1

I will begin performing the migration.

Cheers,
-Rob

> On Jul 7, 2017, at 8:25 AM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> I would like to call a vote by lazy consensus for migrating the codebase of 
> Apache Commons Collections to git.
> 
> This vote will be successful if nobody raises objections within the next 72 
> hours, e.g. by July 10, 2017 1300 (UTC).
> 
> Cheers,
> -Rob


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

Re: commons-numbers git commit: NUMBERS-13: atanh() passes all tests

[Gilles]

Hi Eric.

On Tue, 11 Jul 2017 07:27:42 + (UTC), ericbarnh...@apache.org 
wrote:

Repository: commons-numbers
Updated Branches:
  refs/heads/complex-dev ade98aa18 -> 48464a3cf


NUMBERS-13: atanh() passes all tests


Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
Commit:

http://git-wip-us.apache.org/repos/asf/commons-numbers/commit/48464a3c
Tree: 
http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/48464a3c
Diff: 
http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/48464a3c


Branch: refs/heads/complex-dev
Commit: 48464a3cf57e8a62d97e8c8741cadad23406e4ea
Parents: ade98aa
Author: Eric Barnhill 
Authored: Tue Jul 11 09:29:11 2017 +0200
Committer: Eric Barnhill 
Committed: Tue Jul 11 09:29:11 2017 +0200


--
 .../apache/commons/numbers/complex/Complex.java | 25 
++--

 1 file changed, 23 insertions(+), 2 deletions(-)

--



http://git-wip-us.apache.org/repos/asf/commons-numbers/blob/48464a3c/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java

--
diff --git

a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java

b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
index d3d8aa8..e4c0a71 100644
---

a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
+++

b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
@@ -643,7 +643,7 @@ in the
 public Complex acos() {
 if (real == 0 && Double.isNaN(imaginary)) {
 return new Complex(Math.PI * 0.5, Double.NaN);
-} else if (!Double.isNaN(real) && !Double.isInfinite(real)
&& imaginary == Double.POSITIVE_INFINITY) {
+} else if (neitherInfiniteNorZeroNorNaN(real) && imaginary
== Double.POSITIVE_INFINITY) {
 return new Complex(Math.PI * 0.5, 
Double.NEGATIVE_INFINITY);
 } else if (real == Double.NEGATIVE_INFINITY && imaginary == 
1) {

 return new Complex(Math.PI, Double.NEGATIVE_INFINITY);
@@ -701,7 +701,7 @@ in the
  * @since 1.2
  */
 public Complex asinh(){
-if (!Double.isNaN(real) && !Double.isInfinite(real) &&
imaginary == Double.POSITIVE_INFINITY) {
+if (neitherInfiniteNorZeroNorNaN(real) && imaginary ==
Double.POSITIVE_INFINITY) {
 return new Complex(Double.POSITIVE_INFINITY, Math.PI * 
0.5);

 } else if (real == Double.POSITIVE_INFINITY &&
!Double.isInfinite(imaginary) && !Double.isNaN(imaginary)) {
 return new Complex(Double.POSITIVE_INFINITY, 0);
@@ -729,6 +729,21 @@ in the
  * @since 1.2
  */
 public Complex atanh(){
+if (real == 0  && Double.isNaN(imaginary)) {
+return new Complex(0, Double.NaN);
+} else if (neitherInfiniteNorZeroNorNaN(real) && imaginary 
== 0) {

+return new Complex(Double.POSITIVE_INFINITY, 0);
+} else if (neitherInfiniteNorZeroNorNaN(real) && imaginary
== Double.POSITIVE_INFINITY) {
+return new Complex(0, Math.PI*0.5);
+} else if (real == Double.POSITIVE_INFINITY &&
neitherInfiniteNorZeroNorNaN(imaginary)) {
+return new Complex(0, Math.PI*0.5);
+} else if (real == Double.POSITIVE_INFINITY && imaginary ==
Double.POSITIVE_INFINITY) {
+return new Complex(0, Math.PI*0.5);
+} else if (real == Double.POSITIVE_INFINITY &&
Double.isNaN(imaginary)) {
+return new Complex(0, Double.NaN);
+} else if (Double.isNaN(real) && imaginary ==
Double.POSITIVE_INFINITY) {
+return new Complex(0, Math.PI*0.5);
+}
 return

this.add(Complex.ONE).divide(Complex.ONE.subtract(this)).log().divide(new
Complex(2));
 }


The amount of repeated
  Math.PI*0.5
asks for a named constant:
  private static double HALF_PI = Math.PI / 2;


/**
@@ -1225,4 +1240,10 @@ in the
 private static boolean equals(double x, double y) {
 return new Double(x).equals(new Double(y));
 }
+
+private static boolean neitherInfiniteNorZeroNorNaN(double d) {
+if (!Double.isNaN(d) && !Double.isInfinite(d) && d != 0) {
+return true;
+} else return false;
+}
 }


private static boolean neitherInfiniteNorZeroNorNaN(double d) {
return !Double.isNaN(d) &&
!Double.isInfinite(d) &&
d != 0;
}

Perhaps the "d != 0" should come first (?).

Regards,
Gilles


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

Re: [dbutils] Preparing for Release; Questions

[Carl Hall]

Hey Gary,

Thanks for adding me, but I'm getting the same error message as before.  I
checked my profile in whimsy and I appear to be a committer on commons and
part of the "committers" group.
It might be completely unrelated, but Github and git.a.o aren't in sync
with git-wip-us.a.o.  Maybe some weirdo setup thing somewhere?

On Sun, Jul 9, 2017 at 2:48 PM, Gary Gregory  wrote:

> Hi Carl,
>
> As you already are an Apache Committer, I've added you to the Commons
> Committers group, please try again in a few minutes.
>
> Gary
>
> On Sun, Jul 9, 2017 at 2:08 PM, Carl Hall  wrote:
>
> > Hi all,
> >
> > I'd like to make a release of dbutils.  I've worked through the release
> > preparation guide[1] up to deploying the RC.  Rather expectedly, since
> this
> > is my first attempt at releasing, I'm not able to complete the `mvn
> deploy`
> > step.
> >
> > ```
> > Failed to transfer file:
> > https://repository.apache.org/service/local/staging/deploy/
> > maven2/commons-dbutils/commons-dbutils/1.7/commons-dbutils-1.7.jar.
> > Return code is: 401, ReasonPhrase: Unauthorized.
> > ```
> >
> > Should I ask for write permission or should I ask someone else to manage
> > the release?
> >
> > Thanks,
> > Carl
> >
> > 1 https://commons.apache.org/releases/prepare.html
> >
>