Re: [LANG-1478] Do we need to wait for a major release for this one?

In fact, you don’t even need to change the minor version (assuming this is the only thing being done). You can just do a “point release”, changing only the third digit, or 3.9.1 On Sat, Aug 24, 2019 at 9:43 PM Bruno P. Kinoshita wrote: > I think it makes sense, good to go with 3.x then. Thanks

Re: [pool] OK to commit?

If you feel nervous, you can always push a branch or something and let folks take a look. On Sat, Jul 20, 2019 at 8:06 PM Matt Sicker wrote: > I believe it’s CTR on Pool, so go for it. > > On Sat, Jul 20, 2019 at 18:45, Phil Steitz wrote: > > > I am working on a patch for POOL-361. I think

Re: [IMAGING] Add another backward incompatible change pre alpha2

On Wed, Jun 26, 2019 at 7:15 PM Gary Gregory wrote: > We do not have a 1.0, so it is OK to break BC IMO. +1

Re: [ALL][DRAFT] Apache Commons Board Report for June 2019

Fair enough. And very good point. It only came to mind for me, because of the work stuff. Thanks On Thu, Jun 13, 2019 at 9:09 AM Gary Gregory wrote: > On Thu, Jun 13, 2019 at 8:51 AM James Carman > wrote: > > > SCXML seems to have stalled quite a bit. I’m not trying

Re: [ALL][DRAFT] Apache Commons Board Report for June 2019

I’ve encouraged them to contribute upstream and help out. If a regular project was in this sort of trouble, the PMC would want to report it. Do we need to do the same for our sub modules? On Thu, Jun 13, 2019 at 8:33 AM Gary Gregory wrote: > On Thu, Jun 13, 2019 at 8:30 AM James Carman >

Re: [ALL][DRAFT] Apache Commons Board Report for June 2019

Should we mention the issues with SCXML2? On Thu, Jun 13, 2019 at 8:25 AM Gary Gregory wrote: > ## Description: > - Apache Commons is an Apache project focused on all aspects of reusable >Java components. > > ## Issues: > - There are no issues requiring board attention at this time. > >

Re: [lang] ArrayUtils.addFirst(T[], T)?

I like it. Seems like a logical thing to do. Another idea would be adding at an arbitrary index. On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory wrote: > Hi All: > > We have org.apache.commons.lang3.ArrayUtils.add(T[], T). > > WDYT about adding a method that adds the element at the beginning of

Re: [All] Alpha/beta releases

On Sun, Jun 9, 2019 at 7:36 AM sebb wrote: > > Huh? > That can still cause jar issues, *precisely because* only one jar will > reach the Java classpath. > > Suppose there is jar1 with API-V1. > This is depended on by app1 and app2. > > Then jar2 is produced with API-V2 (not BC-compatible with

Re: [All] Alpha/beta releases

On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski wrote: > > Ultimately the PMC still needs to vote on the release, no? > Hence I don't see what advantage there is in allowing different > beta policies. [Of course, no component is required to provide > a beta release...] > What the proposal aims

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: [All] Alpha/beta releases

, just explaining why I’m having a hard time understanding what you’re doing. Maybe this will be a learning opportunity for me! :) On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 17:04, James Carman a > écrit : > > > > What sort of comparison are

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 > > &

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

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: [SCXML] Are we close to ready for a 2.0 release?

colleagues to get involved and start submitting PRs. Perhaps we'll get some "new blood" to help revive SCXML. Thanks to Ate and Woonsan for their hard work on this library! The folks at work are really digging using it! Thanks, James On Fri, May 17, 2019 at 6:00 PM James Car

[SCXML] Are we close to ready for a 2.0 release?

A coworker of mine was wanting to use SCXML2. Obviously we can't use SNAPSHOTs in production, so I was just wondering if we are close to buttoning up 2.0. If need be, I can offer to help get it out the door (it has been a while). Thanks, James

Resign from PMC...

I wish to resign from the Apache Commons PMC. Thank you.

Re: [ALL] Volunteers for a Math IPMC?

Could we start something in the sandbox? It's not modifying existing code. On Sat, Jun 18, 2016 at 8:43 AM Jörg Schaible wrote: > Hi Gilles, > > Gilles wrote: > > > Hi. > > > > On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote: > >> Gilles, > >> > >> Thanks for links.

Re: [VOTE] Move Commons Math to TLP (again)...

We should probably tally the votes at this point, but it is pretty clear that there is no consensus, unfortunately. I honestly have no idea what to do at this point. I have limited connectivity today. On Fri, Jun 17, 2016 at 12:51 PM Benedikt Ritter <brit...@apache.org> wrote: > James C

Re: [crypto] On Java 6, really?

to maintain that philosophy). On Tue, Jun 14, 2016 at 10:57 AM Gary Gregory <garydgreg...@gmail.com> wrote: > On Jun 14, 2016 7:51 AM, "James Carman" <ja...@carmanconsulting.com> > wrote: > > > > The trick is if we want to require a major version upgrade to bu

Re: [BCEL] Release Candidate on Thursday

mar...@cs.washington.edu> wrote: > 243 is a show stopper for Daikon. It will continue to be shipped with our > private version of BCEL if it is not fixed. > > > -Original Message- > > From: James Carman [mailto:ja...@carmanconsulting.com] > > Sent: Tuesday, June 14, 2016 8

Re: [BCEL] Release Candidate on Thursday

Are they show stoppers? On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts wrote: > I can tell you right now I would vote -1 as you have not picked up the fix > for https://issues.apache.org/jira/browse/BCEL-243. > > Also, I think

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

Can folks perhaps combine commons-io to help? On Tue, Jun 14, 2016 at 11:27 AM Gary Gregory <garydgreg...@gmail.com> wrote: > On Jun 14, 2016 5:19 AM, "James Carman" <ja...@carmanconsulting.com> > wrote: > > > > Are Readers that hard to create? > >

Re: Re: [ALL] About binary compatibility

; > > > * implement this interface. Note that direct > implementers of > > > > this > > > > * interface outside of the framework will be broken in > future > > > > * releases when methods are added t

Re: [crypto] On Java 6, really?

The trick is if we want to require a major version upgrade to bump JDK levels. That's why you'd want to bump it now if possible. On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker wrote: > I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a > 1.0 release

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

Are Readers that hard to create? On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory wrote: > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter > wrote: > > > I don't like how we're evolving CSVFormat. It is becoming a dumping > ground > > for anything that

Re: [DISCUSS] Brining clirr to the ASF?

+1 to Jochen's idea and I'd love to contribute to that effort! On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann wrote: > On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory > wrote: > > >> as Jochen has pointed out, Clirr seems to be unmaintained.

Re: [ALL] About binary compatibility

andahl <t...@apache.org> wrote: > On 13.06.16 20:57, James Carman wrote: > > I'd rather not make it (the OSGi metadata) the "source of truth". > > I'm not insisting on OSGi meta data but I strongly believe that one > (single) sour

Re: [ALL] About binary compatibility

I'd rather not make it (the OSGi metadata) the "source of truth". On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl <t...@apache.org> wrote: > On 05.06.16 20:33, James Carman wrote: > > Not quite. OSGi is a special case. It's much more restrictive than simple

Re: [VOTE] Move Commons Math to TLP (again)...

Software > (TOMS). The latest (Algorithm 959) is interesting although I have no idea > where to find the code and am dismayed that it is a library under the GPL. > > > -Original Message- > > From: Niall Pemberton [mailto:niall.pember...@gmail.com] > > Sent: Sunday, June

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

for the Sun compiler. On Sun, Jun 12, 2016 at 5:49 PM Gary Gregory <garydgreg...@gmail.com> wrote: > On Jun 12, 2016 2:45 PM, "James Carman" <ja...@carmanconsulting.com> > wrote: > > > > I don't off the top of my head. All I have is anecdotal stuff in my > brain,

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

n if/else > chain getting jitted down to a simple hash jumptable > > Original message ---- > From: James Carman <ja...@carmanconsulting.com> > Date: 06/12/2016 5:19 PM (GMT-05:00) > To: Commons Developers List <dev@commons.apache.org> > Subject: Re:

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

I was referring to JIT. On Sun, Jun 12, 2016 at 5:18 PM dbrosIus <dbros...@baybroadband.net> wrote: > Interesting. Source? > > Original message ---- > From: James Carman <ja...@carmanconsulting.com> > Date: 06/12/2016 5:12 PM (GMT-05:00) > To

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

Doesn't it all compiled down to the same thing? It gets optimized at runtime anyway. I would go for the more readable option, unless there are extremely compelling performance numbers. On Sun, Jun 12, 2016 at 4:38 PM Benedikt Ritter wrote: > Yes, the if-else could also be

Re: [LANG] Would CircuitBreaker better fit into [NET]?

Can it be used in non-I/O situations? On Sun, Jun 12, 2016 at 8:15 AM sebb <seb...@gmail.com> wrote: > IO is a better fit than NET, but I'm not sure that it is better than LANG. > > On 12 June 2016 at 13:03, James Carman <ja...@carmanconsulting.com> wrote: > > It has

Re: [LANG] Would CircuitBreaker better fit into [NET]?

gt; > > > Really? When talking about I/O I always think about file system > operations... > > > > > > Am 12.06.2016 um 13:40 schrieb James Carman: > > > Is it only I/O related? > > > > > > On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter <

Re: [LANG] Would CircuitBreaker better fit into [NET]?

Is it only I/O related? On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter wrote: > Hi, > > CircuitBreaker is a pattern usually used when working with remote systems. > We have a CircuitBreaker implementation added to [LANG] in the concurrent > package. Now I'm wondering

[ALL] Volunteers for a Math IPMC?

We (the Commons PMC) have not decided yet what to do, but I just wanted to gauge the interest in joining the math IPMC if we choose to go TLP by way of the incubator. The idea would be that math (whatever its name may be), would go through the incubator in order to enrich its community prior to

Re: [VOTE] Move Commons Math to TLP (again)...

at 1:36 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > -1 (binding) > > At least until there are enough people to have a viable PMC. > > Ralph > > > On Jun 10, 2016, at 8:47 PM, James Carman <ja...@carmanconsulting.com> > wrote: > > > > Sinc

Re: [Math] Commons Math (r)evolution

On Sat, Jun 11, 2016 at 12:48 AM James Carman <ja...@carmanconsulting.com> wrote: > > Phil Seitz > Luc Maisonobe > Gary Gregory > Thomas Neidhart > Gilles Sadowski > William Barker > Otmar Ertl > > Apologies to Phil for misspelling his name, Steitz.

Re: [Math] Commons Math (r)evolution

On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers wrote: > > Personally, I think the vote that took place to move Math to a TLP should > now be considered void since the proposed PMC no longer exists. > Furthermore, at the moment Math doesn’t have a sufficient number of >

Re: [Math] Commons Math (r)evolution

I like the idea of splitting Math into multiple components. Even Phil, in the TLP VOTE thread, said: "We are probably at the point where we should consider splitting [math] itself into separately released subcomponents (could be done in Commons, but starts smelling a little Jakarta-ish when

Re: [VOTE] Move Commons Math to TLP (again)...

Here's my +1 (binding). On Fri, Jun 10, 2016 at 11:47 PM James Carman <ja...@carmanconsulting.com> wrote: > Since it has been suggested that the previously passing vote should be > voided, I propose we vote again to move Commons Math to a TLP: > > +1 - Yes, move Commons

Re: [Math] Commons Math (r)evolution

On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers wrote: > > Personally, I think the vote that took place to move Math to a TLP should > now be considered void since the proposed PMC no longer exists. > Furthermore, at the moment Math doesn’t have a sufficient number of >

[VOTE] Move Commons Math to TLP (again)...

Since it has been suggested that the previously passing vote should be voided, I propose we vote again to move Commons Math to a TLP: +1 - Yes, move Commons Math to a TLP -1 - No, do not move Commons Math to a TLP The vote will remain open for 72 hours. Thank you, James Carman

Re: [Math] Commons Math (r)evolution

On Fri, Jun 10, 2016 at 3:29 PM Ralph Goers wrote: > Not only is the original chair not available, neither is a quorum of the > proposed PMC. Why are you pushing this? I, for one, am perfectly content > to keep Math here and see if those who have expressed interest

Re: [Math] Commons Math (r)evolution

We already voted to make it go TLP and it passed. The original chair of the new project isn't available any more. Gilles, are you willing to chair the new project? Is anyone else willing to help Gilles perhaps take Math through the incubator to gather more momentum? Can we perhaps reach out to

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

On Fri, Jun 10, 2016 at 1:05 PM Gary Gregory wrote: > > I think mailing the list for each component is nice. It seems polite, less > overbearing and less brute-force; IOW more community oriented. The VOTE is > nice because it gives folks a few days to voice and record

Re: [Math] Commons Math (r)evolution

On Fri, Jun 10, 2016 at 12:52 PM Gary Gregory wrote: > I agree with Jörg's email below. Furthermore, to me, the best chance [math] > has a shot to survive and prosper (I'm a glass-half-full kinda guy) is to > stay in Commons in its current single module form (KISS)

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

. That's what I mean. I don't mean force everyone to move right now. On Fri, Jun 10, 2016 at 8:57 AM James Carman <ja...@carmanconsulting.com> wrote: > Is anyone opposed at this time to moving everything at once? > > On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter <brit...@a

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

Is anyone opposed at this time to moving everything at once? On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter wrote: > Jochen Wiedmann schrieb am Fr., 10. Juni 2016 > um 14:14 Uhr: > > > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold > >

Re: [crypto] Logging dependency

I can get on board with that model I suppose. What we talked about long ago was an event listener model for knowing what's going on internally with a library. These events could be delivered asynchronously from the calls coming from an application. On Fri, Jun 10, 2016 at 7:03 AM sebb

Re: [Math] Commons Math (r)evolution

Exactly! On Thu, Jun 9, 2016 at 10:54 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Given how few Math committees there are, that would require going into the > incubator. > > Ralph > > > On Jun 9, 2016, at 6:24 PM, James Carman <ja...@carmanconsulting.com

Re: [Math] Commons Math (r)evolution

TLP TLP TLP! You can split it up into whatever you want. On Sun, Jun 5, 2016 at 8:49 PM Gilles wrote: > Hello. > > Commons Math as it was in the last official release (v3.6.1) and > consequently as it is in the current development branch has > become

Re: [crypto] Logging dependency

I'll check it out. The printf sounds nice On Thu, Jun 9, 2016 at 7:18 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > On Jun 9, 2016, at 3:55 PM, James Carman <ja...@carmanconsulting.com> > wrote: > > > > On Thu, Jun 9, 2016 at 2:19 PM

Re: [crypto] Logging dependency

On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker wrote: > There is a huge list of advantages to using log4j-api over slf4j-api > nowadays, plus I do prefer to use Apache dependencies in Apache projects > unless the competition is clearly better for the use case (like using Jetty >

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

Let's be clear here. We are proposing changing the code because someone used a SNAPSHOT version and released their code which uses it? That code was never released and I don't know that it's right to bind us to a work-in-progress. It's bad enough we have to be saddled forever with the burden of

Re: [crypto] Logging dependency

On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory wrote: > Hi All: > > IMO. if [crypto] is to have a dependency on a logging framework, it should > be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can > pair with any number of implementations: Log4j's own

Re: [crypto] On Java 6, really?

+1 On Tue, Jun 7, 2016 at 1:11 PM Benedikt Ritter wrote: > Hello Sebb, > > sebb schrieb am Di., 7. Juni 2016 um 18:09 Uhr: > > > Does the project *need* to use any Java7 features? > > > > Is it working OK now with Java 6 as the minimum? > > > > If the

Re: BCEL 6 API breakage

On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann wrote: > In the light of the current discussions, you may be right. > > However, what I still don't understand: Why is BC such an issue for people? > > I think, it is perfectly reasonable to do, what other projects do: > >

Re: BCEL 6 API breakage

We have to be willing to reevaluate the BC stringency we have had. Is it working for our users? Is it worth the trouble it causes (people have left this community over it)? Are there better options? Is it too strict and could just be relaxed? Our BC policies sound good on paper and do address

Re: [BCEL] Move to Git?

This was proposed long ago. On Tue, Jun 7, 2016 at 4:46 AM Jochen Wiedmann wrote: > On Tue, Jun 7, 2016 at 10:43 AM, Gary Gregory > wrote: > > > We have a bunch of components that just got in the queue to migrate from > > Svn to Git. BCEL

Re: [BCEL] 5.3 is going to be messy

+1 Torsten On Tue, Jun 7, 2016 at 6:17 AM Torsten Curdt wrote: > > > > 1) I don't believe we should force users to migrate their code in > > order to support java 7/8. > > > > ...and that line of thinking is why it feels like commons projects are > effectively stuck in the

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

+1 On Tue, Jun 7, 2016 at 2:37 AM Kristian Rosenvold wrote: > Hello, > > I'd like to call a VOTE by LAZY > consensus for migrating the Apache Commons IO component to git. Please > object to this vote if you see a problem with this. Otherwise this vote > will be considered

Re: [VOTE][LAZY] Migrate Apache Commons CSV to git

+1 On Mon, Jun 6, 2016 at 3:17 PM Benedikt Ritter wrote: > Hello, > > as done before for other components, I'd like to call a VOTE by LAZY > consensus for migrating the Apache Commons CSV component to git. Please > object to this vote if you see a problem with this.

Re: [ALL] About binary compatibility

On Sun, Jun 5, 2016 at 7:12 PM Ralph Goers wrote: > I think we should adopt Java 9’s multi-release jars [1] as standard > practice. While this won’t let us update our APIs without breaking > compatibility (which may still be necessary), it will allow us to leverage >

Re: [ALL] About binary compatibility

Not quite. OSGi is a special case. It's much more restrictive than simple J2SE, because it can be. In the general case, the public API for OSGi is different from the public API for J2SE. Let's not confuse the two. On Sun, Jun 5, 2016 at 2:30 PM Gary Gregory wrote: > On

Re: Apache Code of Conduct

No, only if it is *enforced* will people start to feel safe and throw out their new ideas. The trick is making people aware that poor behavior won't be tolerated. Enforcement starts with the community stepping in and saying "now, that was uncalled for" or "we do not allow personal attacks" or

Re: [ALL] About binary compatibility

wrote: > James Carman <ja...@carmanconsulting.com> schrieb am Fr., 3. Juni 2016 um > 00:04 Uhr: > > > You've been in karaf land for too long! ;) > > > > It's probably a different story when you're working on a framework. It > pretty unlikely to end up with two ve

Re: [ALL] About binary compatibility

Yep, those pesky duplicate chains. On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies <bimargul...@gmail.com> wrote: > On Thu, Jun 2, 2016 at 6:04 PM, James Carman <ja...@carmanconsulting.com> > wrote: > > You've been in karaf land for too long! ;) > > I took my t

Re: [ALL] About binary compatibility

You've been in karaf land for too long! ;) On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies wrote: > I don't understand what's wrong with semantic versioning and keeping > the same maven coordinates. No sane person should be using RELEASE or > LATEST. > >

Re: [math] avoid allocating distribution bounds if there are no successes

Why not create a release prep branch for each release when ready? The "gitflow" treatment of master is that's what's currently "in production" or whatever. I don't really care for that model, but it is popular. For libraries that support multiple versions, I don't know how realistic that is. On

Re: [Poll][VFS] Switch to Git

+1 On Wed, May 25, 2016 at 4:43 PM Bernd Eckenfels wrote: > Hello, > > I would like to be able to use Git with the Apache Commons VFS repo. As > we agreed upon I call out the intention to do this and ask you for your > oppinion. > > Now that we have the 2.1 release out

Re: [ALL] Dist layout change to per version directories

That definitely seems easier. +1. Would that mess up any sort of sync jobs (maven and stuff)? On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory wrote: > I am OK with anything that makes releasing easier. > > Gary > > On Fri, Apr 15, 2016 at 4:02 PM, sebb

Re: Is there an missing bit in the instructions for making a release?

On Fri, Apr 15, 2016 at 4:13 PM sebb wrote: > > As already explained, this is not possible with Git. > Infra have disabled updating of certain tags includig the ones used > for releases. Sorry, didn't realize if this was something we imposed on ourselves and asked infra to do

Re: Is there an missing bit in the instructions for making a release?

On Fri, Apr 15, 2016 at 1:43 PM sebb wrote: > > "the regular process" is what is under discussion. > > I meant the regular process used by the maven release plugin. :) That's "regular" to me, because that's what I use all the time. I think we have an opportunity to

Re: Is there an missing bit in the instructions for making a release?

On Fri, Apr 15, 2016 at 12:57 PM James Carman <ja...@carmanconsulting.com> wrote: > On Fri, Apr 15, 2016 at 12:53 PM sebb <seb...@gmail.com> wrote: > >> That is effectively what the final release tag is. >> We vote on the RC tag, and create the release tag

Re: Is there an missing bit in the instructions for making a release?

On Fri, Apr 15, 2016 at 12:53 PM sebb wrote: > That is effectively what the final release tag is. > We vote on the RC tag, and create the release tag from the successful RC > tag. > > Yep, we're not far off. What I'm proposing is that we try to use the Maven Release Plugin to

Re: Is there an missing bit in the instructions for making a release?

On Fri, Apr 15, 2016 at 12:38 PM James Carman <ja...@carmanconsulting.com> wrote: > On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies <bimargul...@gmail.com> > wrote: > >> >> The problem is that this PMC does not want a tag named after the real >> (not RC

Re: Is there an missing bit in the instructions for making a release?

On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies wrote: > > The problem is that this PMC does not want a tag named after the real > (not RC) version to come into existence until after the vote passes. > > Well, that's the thing that is somewhat silly. The fact that

Re: Is there an missing bit in the instructions for making a release?

What is with everyone's aversion to using the Maven Release Plugin? I realize that it may not do exactly what we need out of the box, but it's a very useful tool. At home, I push a button in my Jenkins setup and it cuts a new release to the Nexus OSS staging repository awaiting me to finalize

Re: Whatever happened to commons-io 2.5?

I don't think we take away karma, just membership to the PMC. On Mon, Apr 11, 2016 at 12:45 PM Benson Margulies wrote: > I'm a member emeritus. Can I do it without being voted as something else? > > > On Mon, Apr 11, 2016 at 12:33 PM, Gary Gregory

Re: [COLLECTIONS] [DISCUSS] Possible candidate for inclusion in Commons-Collections: OrderedSet (provides composite-key based ordering of a set of values)

gt; *Nonfiction Merriam, George Dictionary... Book 1* > *Nonfiction Webster, NoahDictionary... Book 1* > *Quest Bryson, Bill A Walk... Book 2* > *Reference Merriam, George Dictionary... Book 1* > *Reference Webster, NoahDictionary... Book 1* > *Tra

Re: [COLLECTIONS] [DISCUSS] Possible candidate for inclusion in Commons-Collections: OrderedSet (provides composite-key based ordering of a set of values)

Couldn't you achieve the same thing using any SortedSet and CompareToBuilder? On Fri, Apr 8, 2016 at 2:17 AM Daniel Vimont wrote: > Hello all, > > I've just published a new extension to the standard Java Collections > Framework to both GitHub and the Maven Central

Re: [RESULT][VOTE] Accept Chimera as new Apache Commons Component

be +1 > Sergio Fernández +1 (non-binding) > Uwe Barthel +1 (non-binding) > Emmanuel Bourg +1 > James Carman -0 > sebb -0.9 > Uma Gangumalla +1 (non-binding) > Haifeng Chen +1 (non-binding) > Cheng A Xu +1 (non-binding) > Dong Chen +1 (non-binding) > Oliver Heger + 0

Re: [VOTE] Release Configuration 2.0 based on RC1

+1 drop ant On Mon, Mar 21, 2016 at 5:06 PM Oliver Heger wrote: > Hi Benedikt, > > Am 21.03.2016 um 09:58 schrieb Benedikt Ritter: > > Hello Oliver, > > > > very nice artifacts, good work. > > > > - builds with java 6, 7 and 8 > > - site looks good > > - reports

Re: [VOTE] Accept Chimera as new Apache Commons Component

-0, I don't like the idea of a JNI library. On Mon, Mar 21, 2016 at 4:45 AM Benedikt Ritter wrote: > Hi all, > > after long discussions I think we have gathered enough information to > decide whether we want to accept the Chimera project as a new Apache > Commons component.

Re: [crypto][chimera] Next steps

Still not a fan. My vote stands On Mon, Feb 22, 2016 at 6:37 PM Gary Gregory <garydgreg...@gmail.com> wrote: > We already have commons-daemon that has C bits. > > Gary > On Feb 22, 2016 3:27 PM, "James Carman" <ja...@carmanconsulting.com> > wrote: > &g

Re: [crypto][chimera] Next steps

Not a big fan of introducing JNI-based library to Commons. I'm -0 On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter wrote: > Hi, > > I'd like to discuss the next steps for moving the Chimera component to > Apache Commons. So far, none of the other PMC members has expressed his

Re: [Math] How fast is fast enough?

Okay, folks, this is definitely getting out of hand. Let's put a moratorium on this thread for the weekend or something and try to come back together next week and try to move forward. I would urge folks to watch this while we wait: https://m.youtube.com/watch?v=rOWmrlft2FI p.s. Phil, I do hope

Re: [Math] How fast is fast enough?

Passion is a good thing. It means he gives a damn. Gilles obviously cares quite a bit about the subject matter. I think it's great that he's willing to crack open some code that a lot of folks wouldn't touch and propose some interesting changes. Perhaps adding the new implementations alongside the

Re: [RESULT] [math] Name of the new TLP

Good question. I have proposed it many times in the past On Mon, Feb 1, 2016 at 5:03 PM Gilles <gil...@harfang.homelinux.org> wrote: > On Mon, 01 Feb 2016 15:05:57 +0000, James Carman wrote: > > On Mon, Feb 1, 2016 at 9:50 AM Gilles <gil...@harfang.homelinux.org> > >

Re: [math] [POLL] new TLP name

For the record, I really do like epsilon also. On Mon, Feb 1, 2016 at 12:14 PM James Carman <ja...@carmanconsulting.com> wrote: > Apache Math > > On Mon, Feb 1, 2016 at 12:06 PM Phil Steitz <phil.ste...@gmail.com> wrote: > >> Please select your top choice among

Re: [math] [POLL] new TLP name

Apache Math On Mon, Feb 1, 2016 at 12:06 PM Phil Steitz wrote: > Please select your top choice among the following suggested names > for the new [math]-based TLP. All are welcome and encouraged to > respond. This POLL will be open for 72 hours, at which time two >

Re: [RESULT] [math] Name of the new TLP

On Mon, Feb 1, 2016 at 9:50 AM Gilles wrote: > > "Math" is (a bit?) overwhelming for a team of 5- people. > > In "Commons" there was the rationale of accepting only "common" > algorithms (although that was fairly fuzzy as a limitation). > Not so with that overly

Re: [math] Name of the new TLP

>> On 01/24/2016 04:41 PM, Phil Steitz wrote: > >>> > >>>> > >>>> On Jan 24, 2016, at 3:17 PM, Gilles <gil...@harfang.homelinux.org> > >>>> wrote: > >>>>> > >>>>> > >>&g

Re: [math] Name of the new TLP

lt;phil.ste...@gmail.com> wrote: > > > > > > On 1/24/16 2:16 PM, James Carman wrote: > > > > I guess it depends on the scope of what the new TLP is going to do. > > > > > > This is slightly jumping the gun, as we do have the opportunity in > >

Re: [math] Name of the new TLP

I'm okay with that too. Apache Math On Sun, Jan 24, 2016 at 5:17 PM Gilles <gil...@harfang.homelinux.org> wrote: > Just plain and simple "Apache Math" maybe? > Or is it taken already? > > Gilles > > On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote: > >

Re: [math] Name of the new TLP

I guess it depends on the scope of what the new TLP is going to do. Umbrella projects aren't that popular these days, from what I understand. Maybe an homage to a famous mathematician? Apache Newton? Apache Euler? Apache Euclid? On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz

  1   2   3   4   5   6   7   8   9   10   >