[RESULT][VOTE][LAZY] Migrate Apache Commons CSV to git

Hi Benedikt Ritter schrieb am Mo., 6. Juni 2016 um 21:17 Uhr: > 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. Otherwise this vote > wi

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

On Fri, Jun 10, 2016 at 9:05 AM, Benedikt Ritter wrote: > I'll take care of the migration and keep the ML updated about the progress. Thanks, Benedikt. Who's next in the queue? Jochen -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/u

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

This vote passes by lazy consensus. The following people have voted +1: - Jochen Wiedmann - Sergio Fernández - Gary Gregory - James Carman I'll take care of the migration and keep the ML updated about the progress. Regards, Kristian (Master of ^C^V) 2016-06-07 12:46 GMT+02:00 James Carman : >

Re: [Math] Commons Math (r)evolution

Hi. On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote: Hi Gilles, Gilles wrote: [snip] _Some_ developer(s) should be able to support whatever is in development. Otherwise how can it be deemed "in development"? Just today, two issues were reported on JIRA: https://issues.apache.org/

[IMAGING] Working towards a release?

Hello Gary, are you planning to roll a (long over due) release for Imaging? Benedikt

Re: [compress] Preparing for 1.12

> > > You'll see that findbugs is unhappy about inconsistent synchronization > introduced when I made the finish method of BZip2CompressorOutputStream > synchronized due to COMPRESS-357 > > Yes, blockSorter is accessed unsynchronized in different places, but we > don't need to care as the class isn

Re: [crypto] Logging dependency

FWIW I am not a fan of libraries and frameworks just logging away anyway. What I usually do this days: Have an interface in the library itself. Along the lines of public interface Console { void debug( String message ); } and then have the user of the library pass in an implemen

Re: [crypto] Logging dependency

Hi. On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: FWIW I am not a fan of libraries and frameworks just logging away anyway. What I usually do this days: Have an interface in the library itself. Along the lines of public interface Console { void debug( String message );

Re: [crypto] Logging dependency

On 10 June 2016 at 10:46, Gilles wrote: > Hi. > > On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: >> >> FWIW >> >> I am not a fan of libraries and frameworks just logging away anyway. >> >> What I usually do this days: >> Have an interface in the library itself. Along the lines of >> >>

Re: [Math] Commons Math (r)evolution

Hi Gilles, Gilles wrote: > Hi. > > On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote: [snip] >> MATH-172 is about an enhancement. Unfortunately no-one can currently >> implement it, so we have to wait until someone can or the issue stays >> simply >> unresolved again. You've requested fo

Re: [crypto] Logging dependency

On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote: > On 10 June 2016 at 10:46, Gilles wrote: > > Hi. > > > > On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: > >> > >> FWIW > >> > >> I am not a fan of libraries and frameworks just logging away anyway. > >> > >> What I usually do this days: >

Re: [crypto] Logging dependency

On Fri, 10 Jun 2016 12:34:10 +0200, Torsten Curdt wrote: On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote: On 10 June 2016 at 10:46, Gilles wrote: > Hi. > > On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: >> >> FWIW >> >> I am not a fan of libraries and frameworks just logging away any

Re: [crypto] Logging dependency

> > But I guarantee that there will be other discussions: > Wouldn't you add an "error" method to "Console"? > And there we go again... Not quite the same discussions though. And I was just saying: it works for me. As a side note: I personally think libraries should return errors - not log the

Re: [crypto] Logging dependency

On 10 June 2016 at 11:55, Torsten Curdt wrote: >> >> But I guarantee that there will be other discussions: >> Wouldn't you add an "error" method to "Console"? >> And there we go again... > > > Not quite the same discussions though. > And I was just saying: it works for me. > > As a side note: I

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 wrote: > On

RE: [Math] Commons Math (r)evolution

I think it would be better to spend the time trying to recruit new contributors than it would be to alienate existing ones. Also, the effort required to divide the library into smaller parts would be better spent creating patches. Does anyone have ideas for actively recruiting contributors? Do

Re: [compress] Preparing for 1.12

On 2016-06-10, Torsten Curdt wrote: >> You'll see that findbugs is unhappy about inconsistent synchronization >> introduced when I made the finish method of BZip2CompressorOutputStream >> synchronized due to COMPRESS-357 > My feedback: I'd rather recommend to get rid of the finalize over adding >

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

On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold wrote: > This vote passes by lazy consensus. So, again: Who's next? -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg -

Re: [crypto] Logging dependency

On Fri, 10 Jun 2016 12:55:18 +0200, Torsten Curdt wrote: But I guarantee that there will be other discussions: Wouldn't you add an "error" method to "Console"? And there we go again... Not quite the same discussions though. And I was just saying: it works for me. As a side note: I personal

Re: [Math] Commons Math (r)evolution

+1 Ralph > On Jun 10, 2016, at 4:37 AM, Patrick Meyer wrote: > > I think it would be better to spend the time trying to recruit new > contributors than it would be to alienate existing ones. Also, the effort > required to divide the library into smaller parts would be better spent > creating

Re: [crypto] Logging dependency

> On Jun 10, 2016, at 3:34 AM, Torsten Curdt wrote: > > On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote: > >> On 10 June 2016 at 10:46, Gilles wrote: >>> Hi. >>> >>> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: FWIW I am not a fan of libraries and frameworks ju

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

Jochen Wiedmann schrieb am Fr., 10. Juni 2016 um 14:14 Uhr: > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold > wrote: > > > This vote passes by lazy consensus. > > So, again: Who's next? > Pick one you like. How about FileUpload? > > > > -- > The next time you hear: "Don't reinvent the w

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 > > wrote: > > > > > This vote passes by lazy consensus.

Re: [compress] Preparing for 1.12

On 2016-06-10, Stefan Bodewig wrote: > We have it in two cases, ZipFile and BZip2CompressorOutputStream - > ZipFile uses a volatile flag rather than synchronization and > null-assignment, maybe that's the better option anyway. I've changed the code and findbugs is happy again, updated site build

Re: [crypto] Logging dependency

On 10 June 2016 at 13:39, Ralph Goers wrote: > >> On Jun 10, 2016, at 3:34 AM, Torsten Curdt wrote: >> >> On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote: >> >>> On 10 June 2016 at 10:46, Gilles wrote: Hi. On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: > > FWIW >>>

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

Yes On 10 June 2016 at 13:57, James Carman wrote: > 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 Rosen

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

Perhaps I should re-phrase (may not make a difference, but it could). Can we just say that any component that wishes to migrate can feel free to do so at this time? We don't need a VOTE or anything. If someone gets the cycles and inspiration to do so, they can feel free to go right ahead. That's

Re: commons-compress git commit: better set that flag earlier

On 10 June 2016 at 14:01, wrote: > Repository: commons-compress > Updated Branches: > refs/heads/master 8769bb698 -> bdc5ad445 > > > better set that flag earlier Surely if it matters when the flag is set, then it also matters that there is still a window between checking the flag and setting i

Re: commons-compress git commit: better set that flag earlier

Sorry, ignore that - the code was synchronised in order to ensure safe publication rather than preventing concurrect access. On 10 June 2016 at 15:18, sebb wrote: > On 10 June 2016 at 14:01, wrote: >> Repository: commons-compress >> Updated Branches: >> refs/heads/master 8769bb698 -> bdc5ad44

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

On Fri, Jun 10, 2016 at 2:55 PM, 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 >> wrote: >> >> > This vote passes by lazy consensus. >> >> So, again: Who's next? >> > > Pick one you like. How about

Re: [crypto] Logging dependency

On Fri, Jun 10, 2016 at 4:02 PM, sebb wrote: > Depends on what the implementation does. > > For example: > > @Override > void debug( String message ){ > new Throwable(message).printStackTrace(); > } Even a dumb application developer like me would at least like to see a *bit* of performace. :

Re: [crypto] Logging dependency

Without Java 9, that's pretty much the only way to get the caller line number and other metadata besides the caller class. On 10 June 2016 at 09:44, Jochen Wiedmann wrote: > On Fri, Jun 10, 2016 at 4:02 PM, sebb wrote: > > > Depends on what the implementation does. > > > > For example: > > > >

Re: [crypto] Logging dependency

Matt, there is a big difference between printing the stack trace and walking it to find the info. printing it on every debug call would be insane. Ralph > On Jun 10, 2016, at 8:09 AM, Matt Sicker wrote: > > Without Java 9, that's pretty much the only way to get the caller line > number and oth

Re: [crypto] Logging dependency

Oh, I didn't even notice the printStackTrace() part until now. Good point. On 10 June 2016 at 10:23, Ralph Goers wrote: > Matt, there is a big difference between printing the stack trace and > walking it to find the info. printing it on every debug call would be > insane. > > Ralph > > > On Jun

Re: [crypto] Logging dependency

In any case, if the message String does not give sufficient context to be able to understand where the message originated, then arguably it's not a very good message. On 10 June 2016 at 16:34, Matt Sicker wrote: > Oh, I didn't even notice the printStackTrace() part until now. Good point. > > On 1

Re: [IMAGING] Working towards a release?

Not ATM. It seems to me we had a little flurry of activity a couple of years ago but then nothing happened. I remember messages about releasing what we have as a 1.0 and then following up with a non-BC 2.0 or something like that. The issue is time and the need for someone to take a look from a SME

Re: [Math] Commons Math (r)evolution

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) _because_ a bunch of [math] developer's have left. We have a bunch of people in Commons that

Re: [crypto] Logging dependency

Now we are getting way off topic, but I would argue that a message that contains no specific context information would still be a good message. There is nothing wrong with a debug message of logger.debug(“User: {}, userId); as this contains all the context information you need to determine where

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) _because_ a bunch > of [math] d

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

On Fri, Jun 10, 2016 at 7:14 AM, James Carman wrote: > Perhaps I should re-phrase (may not make a difference, but it could). Can > we just say that any component that wishes to migrate can feel free to do > so at this time? We don't need a VOTE or anything. If someone gets the > cycles and ins

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 their objection > (I do not

Re: [crypto] Logging dependency

On Fri, Jun 10, 2016 at 3:55 AM, Torsten Curdt wrote: > > > > But I guarantee that there will be other discussions: > > Wouldn't you add an "error" method to "Console"? > > And there we go again... > > > Not quite the same discussions though. > And I was just saying: it works for me. > > As a s

Re: [Math] Commons Math (r)evolution

On Fri, Jun 10, 2016 at 9:56 AM, James Carman wrote: > 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 i

Re: [Math] Commons Math (r)evolution

Hi Gary, 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) _because_ a > bunch of [math] developer's have left. We

Re: [Math] Commons Math (r)evolution

On Fri, Jun 10, 2016 at 11:00 AM, Jörg Schaible wrote: > Hi Gary, > > 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 mod

Re: [Math] Commons Math (r)evolution

> On Jun 10, 2016, at 11:00 AM, Jörg Schaible wrote: > > Hi Gary, > > 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 modul

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: [Math] Commons Math (r)evolution

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 in helping out actually do and if others are attracted to fill in the gaps. Ralph >

Re: [Math] Commons Math (r)evolution

>> On Jun 10, 2016, at 11:54 AM, James Carman >> wrote: >> >> 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 >> thr

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 in helping > out actually do

Re: [crypto] Logging dependency

> > > Exactly. It's so simple and it doesn't introduce any deps. > > Whether that's goal one can align with is another matter. > > But it means no logging framework discussions anymore ;) > > The disadvantage of this approach is that you loose the location > information - every log event will come

Re: [crypto] Logging dependency

> Matt, there is a big difference between printing the stack trace and > walking it to find the info. printing it on every debug call would be > insane. > Why would anyone want to do that? https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html And how do you think the loggin

Re: [crypto] Logging dependency

> Now we are getting way off topic, but I would argue that a message that > contains no specific context information would still be a good message. > There is nothing wrong with a debug message of logger.debug(“User: {}, > userId); as this contains all the context information you need to determine

Re: [crypto] Logging dependency

> > > As a side note: I personally think libraries should return errors - not > log > > them. The error logging should happen in the app - not the library. If > you > > have to log errors in the framework there is a good chance your API is > not > > how it should be. > > > > That's not a good answe

Re: [Math] Commons Math (r)evolution

Hello Jörg. On Fri, 10 Jun 2016 12:19:56 +0200, Jörg Schaible wrote: Hi Gilles, Gilles wrote: Hi. On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote: [snip] MATH-172 is about an enhancement. Unfortunately no-one can currently implement it, so we have to wait until someone can or the

RE: [Math] Commons Math (r)evolution

Hi Patrick, and others. On Fri, 10 Jun 2016 07:37:00 -0400, Patrick Meyer wrote: I think it would be better to spend the time trying to recruit new contributors than it would be to alienate existing ones. By what are you alienated? [This is addressed to all readers and would-be contributors to

[bcel] console logging

I see this in [bcel]: System.out.println(buf.toString()); e.printStackTrace(); Should that be left in there or removed? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in

Re: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

On Thu, Jun 9, 2016 at 8:22 AM, Benedikt Ritter wrote: > Why? This was a good idea. > The links didn't get generated properly when I looked at it in the staging area - instead of "http://commons.apache.org/proper/commons-crypto/"; it was generating "http://commons.apache.org/crypto/"; and I coul

Re: [bcel] console logging

On 11 June 2016 at 00:15, Gary Gregory wrote: > I see this in [bcel]: > > System.out.println(buf.toString()); > e.printStackTrace(); > > Should that be left in there or removed? Where is it? > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persi

Re: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

On 11 June 2016 at 00:31, Niall Pemberton wrote: > On Thu, Jun 9, 2016 at 8:22 AM, Benedikt Ritter wrote: > >> Why? This was a good idea. >> > > The links didn't get generated properly when I looked at it in the staging > area - instead of "http://commons.apache.org/proper/commons-crypto/"; it wa

Re: [Math] Commons Math (r)evolution

Hi James. On Fri, 10 Jun 2016 20:26:07 +, James Carman wrote: 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

Re: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

On Sat, Jun 11, 2016 at 12:37 AM, sebb wrote: > On 11 June 2016 at 00:31, Niall Pemberton > wrote: > > On Thu, Jun 9, 2016 at 8:22 AM, Benedikt Ritter > wrote: > > > >> Why? This was a good idea. > >> > > > > The links didn't get generated properly when I looked at it in the > staging > > area

Re: [bcel] console logging

On Fri, Jun 10, 2016 at 4:33 PM, sebb wrote: > On 11 June 2016 at 00:15, Gary Gregory wrote: > > I see this in [bcel]: > > > > System.out.println(buf.toString()); > > e.printStackTrace(); > > > > Should that be left in there or removed? > > Where is it? > org.apache.bcel

Re: [bcel] console logging

On 11 June 2016 at 01:41, Gary Gregory wrote: > On Fri, Jun 10, 2016 at 4:33 PM, sebb wrote: > >> On 11 June 2016 at 00:15, Gary Gregory wrote: >> > I see this in [bcel]: >> > >> > System.out.println(buf.toString()); >> > e.printStackTrace(); >> > >> > Should that be left

Re: [Math] Commons Math (r)evolution

As someone relatively new to the project, I feel like my statement here may have a little weight. First, I do really want to help in whatever capacity I am able (given that I’m a tad over-run currently with a new[ish] 2-month-old baby). That said, I am perfectly willing to contribute in whatever

Re: [Math] Commons Math (r)evolution

> On Jun 10, 2016, at 1:26 PM, James Carman wrote: > > 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 i

[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 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 > participants to make it a via

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

Here's my +1 (binding). On Fri, Jun 10, 2016 at 11:47 PM James Carman 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 Math to a TLP > -1 - No, do not move Commons Math to a

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 Commo

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 > participants to make it a via

Re: [Math] Commons Math (r)evolution

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

Re: [crypto] Logging dependency

> On Jun 10, 2016, at 2:56 PM, Torsten Curdt wrote: > >> Matt, there is a big difference between printing the stack trace and >> walking it to find the info. printing it on every debug call would be >> insane. >> > > Why would anyone want to do that? > > https://docs.oracle.com/javase/7/docs/

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

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

Re: [Math] Commons Math (r)evolution

> On Jun 10, 2016, at 8:48 PM, James Carman wrote: > > 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

Any commons project to refer standard datastructures and algorithms implementation

Hi I would like to know if there is an umbrella project under which basic datastructures and algorithm implementations exist. If there is one please let me know Else; I am looking at things such as  - Apache commons standard / style of interfaces for Trees, Graphs and the various algorithm