Re: [all] Is it possible to commit from github via gitbox?

(please remember to CC me on replies) On Wed, 5 Jun 2019 at 16:00, Alex Herbert wrote: > > > On 5 Jun 2019, at 23:51, Eitan Adler wrote: > > (please remember to CC me on replies) > > When I want to merge a PR [0] it seems I don't have write permission > according to github. Is this intentional

Re: [all] Is it possible to commit from github via gitbox?

> On 5 Jun 2019, at 23:51, Eitan Adler wrote: > > (please remember to CC me on replies) > > When I want to merge a PR [0] it seems I don't have write permission > according to github. Is this intentional such that I should push directly > to gitbox, did I miss some step, or do I need to file

[all] Is it possible to commit from github via gitbox?

(please remember to CC me on replies) When I want to merge a PR [0] it seems I don't have write permission according to github. Is this intentional such that I should push directly to gitbox, did I miss some step, or do I need to file an INFRA ticket? [0]

[numbers][fraction] pulling fraction-dev into master

For some months I worked on the Fraction class on a fraction-dev branch, now others are furthering it, but IIUC working off of master, plus it sounds like my edits are out of date in other ways. So within the next day, I will pull fraction-dev into master. I would request any other contributors

Re: [All] Alpha/beta releases

Hi All: I see two lines of usage IRL from people: - I use whatever is "released" on Maven Central. I quote the word released since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and -betas. - I am not allowed to use alpha, beta, or SNAPSHOT versions. The reality ends up being that

Re: [rng] Update ProviderBuilder factory methods

> On 5 Jun 2019, at 22:51, Gilles Sadowski wrote: > > Hi. > > Le lun. 3 juin 2019 à 16:49, Alex Herbert > a écrit : >> >> Can I get a review of a PR that changes the ProviderBuilder [1]? >> >> The aim is to move the creation of the seed and the RNG into the

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 23:14, sebb a écrit : > > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski wrote: > > > > Le mer. 5 juin 2019 à 17:57, James Carman a > > écrit : > > > > > > I’m having a hard time understanding the comparing APIs use case. If I > > > were to want to try that, I’d create a

Re: [rng] Update ProviderBuilder factory methods

Hi. Le lun. 3 juin 2019 à 16:49, Alex Herbert a écrit : > > Can I get a review of a PR that changes the ProviderBuilder [1]? > > The aim is to move the creation of the seed and the RNG into the > RandomSourceInternal. > > This allows for customisation of the seed creation on a per-RNG basis. >

Re: [All] Alpha/beta releases

On June 5, 2019 at 12:16:33, Gilles Sadowski (gillese...@gmail.com) wrote: Le mer. 5 juin 2019 à 17:57, James Carman a écrit : > > I’m having a hard time understanding the comparing APIs use case. If I > were to want to try that, I’d create a branch and import the new dependency > version and

Re: [All] Alpha/beta releases

On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski wrote: > > Le mer. 5 juin 2019 à 17:57, James Carman a > écrit : > > > > I’m having a hard time understanding the comparing APIs use case. If I > > were to want to try that, I’d create a branch and import the new dependency > > version and see what

Re: [gsoc] Weekly meeting tomorrow

> On 5 Jun 2019, at 20:47, Eric Barnhill wrote: > > That looked like a list of times. It showed ideal points for a meeting from all times of day. UTC +3 or +4 should be daytime hours for everyone except those in IST. > How is this one for you all > >

Re: [gsoc] Weekly meeting tomorrow

That looked like a list of times. How is this one for you all https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=6=6=16=0=0=136=224=265=1249=1860=1800 On Wed, Jun 5, 2019 at 11:59 AM Alex Herbert wrote: > Time for another meeting to discuss progress. > > Shall we change to

Re: [gsoc] Weekly meeting tomorrow

Time for another meeting to discuss progress. Shall we change to UTC +4 this time? Here is the meeting time clock for everyone: https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190606=136=224=265=1249=1860

Re: [All] Alpha/beta releases

In the past we have only guarded against jar-hell with major component releases matching a package name changes and Maven coordinate name change. It seems some want to apply the same principles to other kinds of versions, not just major version. Like a 0.9.alpha1 or even a 2.0.beta-1. I suppose

Re: [All] Alpha/beta releases

On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski wrote: > > Case mainly in point is getting to the first release of new components. > This is happening now for [Imaging], and will be soon (hopefully) for > [Numbers], [Statistics] and [Geometry]. > Okay, so the main issue is getting releases out

Re: [beanutils] Towards 1.10

I suppose doing both wouldn’t be unreasonable. It’ll take me a few weeks as I’m in the ramp up phase at a new gig. But I’ll start heading that direction. -Rob > On Jun 5, 2019, at 8:39 AM, Melloware wrote: > > Do you think we could also get a BeanUtils2 release while we are at it? It >

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 17:57, James Carman a écrit : > > I’m having a hard time understanding the comparing APIs use case. If I > were to want to try that, I’d create a branch and import the new dependency > version and see what breaks. The performance part I wouldn’t think I’d use > one code

Re: [All] Alpha/beta releases

I’m having a hard time understanding the comparing APIs use case. If I were to want to try that, I’d create a branch and import the new dependency version and see what breaks. The performance part I wouldn’t think I’d use one code base either. I’m not suggesting my way is the only or best way,

Re: [All] Alpha/beta releases

Maybe we should have a separate maven repo for alpha and beta releases. That could make them less likely to cause jar hell conflicts. It could even be similar to snapshots if they’re not voted on. On Wed, Jun 5, 2019 at 10:33, Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 17:04, James Carman

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 17:04, James Carman a écrit : > > What sort of comparison are you looking to do within the same code? > Performance? Yes, that's one possibility; another is comparing different APIs. Gilles [...] -

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 17:02, James Carman a écrit : > > Wouldn’t you have a package collision between two different alpha releases? Ah, I got it: In "1.0-alpha1", class "o.a.c.somecomp.alpha1.Foo". In "1.2-alpha1", class "o.a.c.somecomp.alpha1.Foo". But those 2 classes can very well be

Re: [All] Alpha/beta releases

What sort of comparison are you looking to do within the same code? Performance? On Wed, Jun 5, 2019 at 10:54 AM Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 16:22, sebb a écrit : > > > > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski > wrote: > > > > > > Le mer. 5 juin 2019 à 15:59, sebb a

Re: [All] Alpha/beta releases

Wouldn’t you have a package collision between two different alpha releases? On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 16:47, James Carman a > écrit : > > > > Ok, what about 1.2? > > How is it different? > > Gilles > > > > > On Wed, Jun 5, 2019 at 10:44 AM

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 16:47, James Carman a écrit : > > Ok, what about 1.2? How is it different? Gilles > > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski > wrote: > > > Le mer. 5 juin 2019 à 16:18, James Carman a > > écrit : > > > > > > What happens if/when you want to release a 2.0-alpha1

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 16:22, sebb a écrit : > > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski wrote: > > > > Le mer. 5 juin 2019 à 15:59, sebb a écrit : > > > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > > > > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > > > > >

Re: [All] Alpha/beta releases

Ok, what about 1.2? On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 16:18, James Carman a > écrit : > > > > What happens if/when you want to release a 2.0-alpha1 in the future? > > Hmm, what happens? > [At point, we'd have renamed "o.a.c.compid" to

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 16:18, James Carman a écrit : > > What happens if/when you want to release a 2.0-alpha1 in the future? Hmm, what happens? [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".] Gilles > > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski wrote: > > > Hello. > > >

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 16:18, Gary Gregory a écrit : > > On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski > wrote: > > > Le mer. 5 juin 2019 à 15:59, sebb a écrit : > > > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski > > wrote: > > > > > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : >

Re: [All] Alpha/beta releases

On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski wrote: > > Le mer. 5 juin 2019 à 15:59, sebb a écrit : > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > > > > I'm not sure what problem this is trying to solve. > > > > > >

Re: [All] Alpha/beta releases

On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 15:59, sebb a écrit : > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski > wrote: > > > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > > > > I'm not sure what problem this is trying to solve. > > > >

Re: [All] Alpha/beta releases

What happens if/when you want to release a 2.0-alpha1 in the future? On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski wrote: > Hello. > > Does someone see a practical way to automate package names > and source files conversions so that each all alpha/beta releases > can be used together (e.g. to

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 16:04, Gary Gregory a écrit : > > On Wed, Jun 5, 2019 at 9:59 AM sebb wrote: > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > > > > I'm not sure what problem this is trying to solve. > > > > > > >

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 15:59, sebb a écrit : > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > > I'm not sure what problem this is trying to solve. > > > > > > How is it intended to use the facility? > > > > Ideally: > > $

Re: [All] Alpha/beta releases

On Wed, Jun 5, 2019 at 9:59 AM sebb wrote: > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > > I'm not sure what problem this is trying to solve. > > > > > > How is it intended to use the facility? > > > > Ideally: > > $ mvn

Re: [All] Alpha/beta releases

On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > I'm not sure what problem this is trying to solve. > > > > How is it intended to use the facility? > > Ideally: > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1 >

Re: [All] Alpha/beta releases

Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > I'm not sure what problem this is trying to solve. > > How is it intended to use the facility? Ideally: $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1 where the latter profile would take care of changing the toplevel

Will there be a SCXML2 release any time?

Hi all, Just wanted to ask if we can expect a release of SCXML2 soon? Otherwise we’ll have to drop that component we were using it in the PLC4X project. Don’t want to have our release-managers do the extra checks needed for having SNAPSHOTS in our releases. Chris

Re: [All] Alpha/beta releases

I'm not sure what problem this is trying to solve. How is it intended to use the facility? On Tue, 4 Jun 2019 at 17:35, Matt Sicker wrote: > > This sounds like a shade feature, yes. However, in order to > automatically extract the version extra data and detect a version > keyword like "alpha"

Re: [beanutils] Towards 1.10

Do you think we could also get a BeanUtils2 release while we are at it?  It supports Java 8 and has many fixes in the last 3 years. On 6/5/2019 8:37 AM, Rob Tompkins wrote: I can try to backport the fix to the 1.X branch. -Rob On 6/5/2019 8:09 AM, Melloware wrote: Rob, I 100% agree since

Re: [beanutils] Towards 1.10

I can try to backport the fix to the 1.X branch. -Rob On 6/5/2019 8:09 AM, Melloware wrote: Rob, I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we need a release. However the 1.X branch seems dormant it seems for the last 3 years everything has been working on is

[VOTE][RESULT] Release Apache Commons CSV 1.7 based on RC1

This vote passes with the following binding PMC +1 votes: - Alex Herbert - Gary Gregory - Bruno P. Kinoshita Gary On Sat, Jun 1, 2019 at 8:31 PM Gary Gregory wrote: > We have fixed quite a few bugs and added some enhancements since Apache > Commons CSV 1.6 was released, so I would like to

Re: [beanutils] Towards 1.10

Note that BeanUtils 2 is a major update with a package name change, meaning it is not a drop in replacement. The one main remaining issue to discuss IIRC is whether the BU API should make public Commons Collections interface and classes, as opposed to more generic JRE Collections. Gary On Wed,

Re: [Geometry] Build aborted on Jenkins

Hello. Le ven. 31 mai 2019 à 20:54, Karl Heinz Marbaise a écrit : > > Hi, > > I have created an INFRA ticket, cause one module is stuck and for all > builds which blocks the whole build process.. > > https://issues.apache.org/jira/browse/INFRA-18546 Ticket has been closed but the problem hasn't

Re: [beanutils] Towards 1.10

Rob, I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we need a release. However the 1.X branch seems dormant it seems for the last 3 years everything has been working on is BeanUtils2 which is where all the fixes have been made? Mello

Re: *** GMX Spamverdacht *** Aw: Re: Proposal to introduce JUnit 5 in commons-numbers

On Tue, 4 Jun 2019 at 16:09, Heinrich Bohne wrote: > So, if the migration from JUnit 4 to JUnit 5 has to happen > instantaneously, how about creating a new branch for the migration? It's > a lot of files that have to be refactored, which is going to take some > time, and since the changes will