Re: Release Commons Pool 1.5.6 based on RC2
On Mar 31, 2011, at 11:30 AM, Simone Tripodi wrote: Mr President, IMHO you vote worths 1000 times more than my binding one, thanks for ^ | You forgot the '.' + reviewing our work!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Mar 31, 2011 at 2:58 PM, Jim Jagielski j...@jagunet.com wrote: +1 (non-binding obviously): OS X, Fed14. On Mar 30, 2011, at 2:17 AM, Phil Steitz wrote: The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 The distribution zips/tars are here: http://people.apache.org/~psteitz/pool-1.5.6-rc2/ Maven artifacts are here: http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ Site: http://people.apache.org/~psteitz/pool-1.5.6-rc2/docs/ Release notes: http://people.apache.org/~psteitz/pool-1.5.6-rc2/RELEASE-NOTES.txt Votes, please. This vote will close in 72 hours (2 April, 06:30 GMT). Thanks in advance. Phil - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Pool 1.5.6 based on RC2
+1 (non-binding obviously): OS X, Fed14. On Mar 30, 2011, at 2:17 AM, Phil Steitz wrote: The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 The distribution zips/tars are here: http://people.apache.org/~psteitz/pool-1.5.6-rc2/ Maven artifacts are here: http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ Site: http://people.apache.org/~psteitz/pool-1.5.6-rc2/docs/ Release notes: http://people.apache.org/~psteitz/pool-1.5.6-rc2/RELEASE-NOTES.txt Votes, please. This vote will close in 72 hours (2 April, 06:30 GMT). Thanks in advance. Phil - 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: [POOL] Ready for 1.5.6
On Mar 24, 2011, at 7:34 AM, Mark Thomas wrote: On 23/03/2011 20:01, Mark Thomas wrote: On 23/03/2011 19:54, Phil Steitz wrote: On 3/23/11 12:36 PM, Mark Thomas wrote: Phil, I believe all the pool issues for 1.5.x have been resolved. Over to you... :) Thanks! You are awesome, Mark! I will finish reviewing your last set of commits and then roll an RC. Did you see my (hopefully baseless) memory leak fear about the fix for POOL-181? I just did. My mail was slow this afternoon. Looking at it now. I think a few changes will be required. Changes complete and test cases updated. I think we are good to go now. fwiw: looks good based on my testing... - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Start work on 2.0?
On Sep 14, 2010, at 6:20 AM, Mark Thomas wrote: On 14/09/2010 11:17, Benoit Perroud wrote: Dear all, Regarding 1) Replace wait/notify with 1.5+ thread management Is there already any work or ideas on how to use Java util concurrent (JUC) http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/ I'd like to bring these two code bases together if at all possible. ++1... The above has shown to be pretty stable. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 1.5.5 based on RC2
On Sep 5, 2010, at 3:57 PM, Phil Steitz wrote: The distribution zips/tars are here: http://people.apache.org/~psteitz/pool-1.5.5-rc2/ Maven artifacts are here: http://people.apache.org/~psteitz/pool-1.5.5-rc2/maven/ Site: http://people.apache.org/~psteitz/pool-1.5.5-rc2/docs/ Release notes: http://people.apache.org/~psteitz/pool-1.5.5-rc2/RELEASE-NOTES.txt Release tag: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_5_RC2/ Votes, please. This vote will close in 72 hours (5 Sept, 20:00 GMT). Thanks in advance. Phil [ ] +1 Proceed with release [ ] +0 OK, but... [ ] -0 Would really like to see... [ ] -1 I am not in favor of this release, because... +1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release DBCP 1.3/1.4 - take three
On Dec 30, 2009, at 6:31 AM, sebb wrote: The 1.3 code builds and tests OK with Java 1.4.2 and 1.5.0, but generates a lot of stack traces from TestManual.testLogWriter(). Ideally the output should be suppressed. However, compilation fails when using Java 1.6.0. Unfortunately the POM says: !-- Target Java versions are actually 1.4, 1.5 and 1.6 -- Also README says: This release of JDBC compiles with and supports JDK 1.4-1.5 (JDBC 3.0) and JDK 1.6 (JDBC 4.0). The 1.4 binary release requires JDK 1.6 (JDBC 4.0). The 1.3 binary release was built from filtered versions of the same sources using JDK 1.5.0_19. The compilation errors seem to be all instances of concrete classes failing to override abstract methods. It may be possible to fix it so that the code will compile OK with Java 1.6.0, but if not, the descriptions should be updated, as this is unusual and unexpected behaviour (AFAIK, all other commons components are upwards compatible). I think this warrants a -1. Tested on OS X using Java 5 and 6 and can confirm the above. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
On Dec 8, 2009, at 7:51 AM, Mark Thomas wrote: Phil Steitz wrote: I have prepared release candidates for DBCP 1.3 and 1.4. Please all interested parties have a look and test. If all goes well, I will kick off a release VOTE based on these artifacts in the next couple of days. I see these as really two sets of artifacts associated with one release, so I am inclined to just do one VOTE including both versions. If anyone disagrees with this, please speak up. I am happy to run two VOTEs. They look good to me. +1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 1.5.4 based on RC1
On Nov 12, 2009, at 9:20 PM, Phil Steitz wrote: We have found and fixed another pool 1.5 regression (POOL-152) and we would like to cut a patch release including the fix. Release distributions: http://people.apache.org/~psteitz/pool-1.5.4-RC1/ Maven artifacts: http://people.apache.org/~psteitz/pool-1.5.4-RC1/maven/ Site (not included with distributions, not yet updated to reflect release): http://people.apache.org/~psteitz/pool-1.5.4-RC1/site/ Tag: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_4_RC1/ Votes, please. This vote will close in 72 hours (02:15:00 16-Nov-09) [ ] +1 release 1.5.4 [ ] -1 no, because... +1. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r817291 - /commons/sandbox/runtime/trunk/src/main/java/org/apache/commons/runtime/util/Utils.java
On Sep 21, 2009, at 11:51 AM, Jim Jagielski wrote:
On Sep 21, 2009, at 11:34 AM, mt...@apache.org wrote:
+private static final String [] try_envs = {
+TMP,
+TEMP,
+TMPDIR,
+TEMPDIR
+};
Not sure about that ordering, unless we want to favor Windows.
For Unix the canonical envvar is TMPDIR, so it should likely be
checked 1st (and this the 1st element), and then go down the others...
Of course, we could even get more sophisticated and have 2; one for
Windows and another for non-Windows, so the ordering makes more sense
depending on the platform ;)
OK if I fold something like that in?
Didn't hear back, so I'll be conservative and not do so...
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r817291 - /commons/sandbox/runtime/trunk/src/main/java/org/apache/commons/runtime/util/Utils.java
On Sep 22, 2009, at 10:56 AM, Mladen Turk wrote:
On 22/09/09 16:06, Jim Jagielski wrote:
On Sep 21, 2009, at 11:51 AM, Jim Jagielski wrote:
On Sep 21, 2009, at 11:34 AM, mt...@apache.org wrote:
+ private static final String [] try_envs = {
+ TMP,
+ TEMP,
+ TMPDIR,
+ TEMPDIR
+ };
Not sure about that ordering, unless we want to favor Windows.
For Unix the canonical envvar is TMPDIR, so it should likely be
checked 1st (and this the 1st element), and then go down the
others...
Of course, we could even get more sophisticated and have 2; one for
Windows and another for non-Windows, so the ordering makes more
sense
depending on the platform ;)
OK if I fold something like that in?
Didn't hear back, so I'll be conservative and not do so...
It's just like with APR. See unix/tempdir.c
The order is: TMP, TEMP, TMPDIR (and I added TEMPDIR)
which itself was based on Python 2.2 (earlier used TMPFILE) :)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r817291 - /commons/sandbox/runtime/trunk/src/main/java/org/apache/commons/runtime/util/Utils.java
On Sep 22, 2009, at 11:51 AM, Jim Jagielski wrote:
On Sep 22, 2009, at 10:56 AM, Mladen Turk wrote:
On 22/09/09 16:06, Jim Jagielski wrote:
On Sep 21, 2009, at 11:51 AM, Jim Jagielski wrote:
On Sep 21, 2009, at 11:34 AM, mt...@apache.org wrote:
+ private static final String [] try_envs = {
+ TMP,
+ TEMP,
+ TMPDIR,
+ TEMPDIR
+ };
Not sure about that ordering, unless we want to favor Windows.
For Unix the canonical envvar is TMPDIR, so it should likely be
checked 1st (and this the 1st element), and then go down the
others...
Of course, we could even get more sophisticated and have 2; one for
Windows and another for non-Windows, so the ordering makes more
sense
depending on the platform ;)
OK if I fold something like that in?
Didn't hear back, so I'll be conservative and not do so...
It's just like with APR. See unix/tempdir.c
The order is: TMP, TEMP, TMPDIR (and I added TEMPDIR)
which itself was based on Python 2.2 (earlier used TMPFILE) :)
FWIW, later versions of Python use my ordering:
# First, try the environment.
for envname in 'TMPDIR', 'TEMP', 'TMP':
dirname = _os.getenv(envname)
if dirname: dirlist.append(dirname)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r817291 - /commons/sandbox/runtime/trunk/src/main/java/org/apache/commons/runtime/util/Utils.java
On Sep 22, 2009, at 12:33 PM, Mladen Turk wrote: On 22/09/09 18:05, Jim Jagielski wrote: # First, try the environment. for envname in 'TMPDIR', 'TEMP', 'TMP': OK. You've convinced me :) *grin* :) Cheers! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r817291 - /commons/sandbox/runtime/trunk/src/main/java/org/apache/commons/runtime/util/Utils.java
On Sep 21, 2009, at 11:34 AM, mt...@apache.org wrote:
+private static final String [] try_envs = {
+TMP,
+TEMP,
+TMPDIR,
+TEMPDIR
+};
Not sure about that ordering, unless we want to favor Windows.
For Unix the canonical envvar is TMPDIR, so it should likely be
checked 1st (and this the 1st element), and then go down the others...
Of course, we could even get more sophisticated and have 2; one for
Windows and another for non-Windows, so the ordering makes more sense
depending on the platform ;)
OK if I fold something like that in?
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Pool 1.5.3
On Sep 18, 2009, at 9:56 AM, Jim Jagielski wrote: On Sep 18, 2009, at 1:31 AM, Henri Yandell wrote: +1. Keys good. Sigs good. Manifest looks good on jar. Javadoc has correct version. NOTICE good. LICENSE good. RELEASE NOTES good (matches JIRA). Source unpacks happily and builds a jar without problem. Confirmed the above... Plus: init: compile: compile-test: [javac] Compiling 28 source files to /Users/jim/Documents/ Downloads/commons-pool-1.5.3-src/build/test-classes test: [echo] Because we need to sleep to test the eviction threads, this takes a little while (around 2 minutes)... [junit] Running org.apache.commons.pool.TestAll [junit] Tests run: 242, Failures: 0, Errors: 0, Time elapsed: 117.673 sec BUILD SUCCESSFUL Total time: 1 minute 59 seconds Will do additionals later on today. All additional tests passed... +1 (non-binding *sob*) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Pool 1.5.3
On Sep 18, 2009, at 1:31 AM, Henri Yandell wrote: +1. Keys good. Sigs good. Manifest looks good on jar. Javadoc has correct version. NOTICE good. LICENSE good. RELEASE NOTES good (matches JIRA). Source unpacks happily and builds a jar without problem. Confirmed the above... Plus: init: compile: compile-test: [javac] Compiling 28 source files to /Users/jim/Documents/ Downloads/commons-pool-1.5.3-src/build/test-classes test: [echo] Because we need to sleep to test the eviction threads, this takes a little while (around 2 minutes)... [junit] Running org.apache.commons.pool.TestAll [junit] Tests run: 242, Failures: 0, Errors: 0, Time elapsed: 117.673 sec BUILD SUCCESSFUL Total time: 1 minute 59 seconds Will do additionals later on today. So +1 (non-binding) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL] Timing of a 1.5.3 release?
On Sep 17, 2009, at 6:56 AM, Phil Steitz wrote: Mark Thomas wrote: POOL-149 impacts Grails badly. The Grails project is aiming to release Grails 1.2 soon and they need a 1.5.3 release or they'll have to drop back to 1.4.x I'd really like to see Grails using pool 1.5.x as it offers a good opportunity to get feedback on the new sync code in pool. Phil - if memory serves me correctly you indicated that you would be up for RM'ing a pool 1.5.3 release? Is that still the case and if so, what is the likely timing. If there is anything I can do to help by way of preparatory work, do let me know. I will roll an RC this eve and kick off a VOTE. Cool. I have some cycles tomorrow and the weekend to run tests. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CLI] Simple usage message
On Sep 2, 2009, at 3:10 PM, Michael Heuer wrote: Jim Jagielski wrote: There are times when add in -h/--help and want to allow people to just go ahead and call the app with that option. The rub is, of course, if there are any required options, in addition to the usage message they also get a superfluous Missing required note as well... This is, imo at least, ugly. If the consensus is that this would be something nice to fix in the 1.x tree (not sure if still an issue in 2.x), I'll open a JIRA and start work. There is a workaround if you have only one required option: Options options = ...; Option requiredOption = ...; requiredOption.setRequired(false); Option help = ...; help.setRequired(false); OptionGroup requiredOptions = new OptionGroup(); requiredOptions.addOption(required); requiredOptions.addOption(help); requiredOptions.setRequired(true); options.addOptionGroup(requiredOptions); but this doesn't work if you have more than one required option. +1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL] 1.5-RC2 soak test errors
Trying to duplicate... On Jun 2, 2009, at 3:03 PM, sebb wrote: I've been running the GKOP and GOP tests repeatedly, and there are some tests which still fail now and then: The following test fails regularly: testThreaded1(org.apache.commons.pool.impl.TestGenericObjectPool) Time elapsed: 6 sec FAILURE! junit.framework.AssertionFailedError: Thread 18 failed: java.util.NoSuchElementException: Timeout waiting for idle object even on an otherwise idle system There are 20 threads competing for 15 objects, with a timeout of 1000ms; each thread may hold the object for 50ms. Not quite sure how this can cause the problem unless there is some unfairness in the allocation. The same test for GKOP fails much less often, which is interesting. I've also seen the following, but only when the system is busy: testEvictionOrder (org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 1.36 sec FAILURE! junit.framework.AssertionFailedError: expected:5 but was:4 BTW, I added pool.clear(); followed by a check that numIdle == 0 to the tearDown() methods in TGOP and TGKOP, and have not yet seen an error, so at least that appears OK. This change has not yet been committed. - 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: [cli] New Parser available
Very cool! You are taking all the fun stuff :) On Sat, May 30, 2009 at 04:13:38PM +0200, Emmanuel Bourg wrote: The new parser has landed, get it while it's hot! It implements the features of the other parsers and more: - partial matching for the long options (-ver instead of -version) - options like Java memory settings are supported (-Xmx512m) - several corner cases have been fixed The parser passes all the tests of the other parsers, not only those in ParserTestCase. Have fun, Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] any takers for CODEC-75 patch?
On May 28, 2009, at 4:33 AM, sebb wrote: On 28/05/2009, Julius Davies juliusdav...@gmail.com wrote: Hi, I created CODEC-75 (url-safe Base64) and attached a 20KB patch to the ticket. Anyone interested in committing this? The patch improves codec's base64 handling in two ways: 1. Ability to decode base64 streams which are missing the final padding characters. That changes the behaviour; there may be some applications that rely on detecting invalid Base64 data. IMO this new behaviour needs to be optional. +1 2. Introduces Base64.encodeBase64URLSafe() method. It appears (very cursory look-see on my part) that URL-Safe is part of the reason Hadoop went elsewhere for its Base64: http://issues.apache.org/jira/browse/HBASE-272 -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/ - 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: [compress] Two issues with releasing the release
+1. The release was/is fine :) On May 21, 2009, at 4:58 PM, Christian Grobmeier wrote: Thanks Rainer. I did the fix and wait for the mirroring now. Hopefully everything works then. I don't think this does require a new vote, RC, etc. since it was just a broker link... right guys? Thanks again, Christian Concerning the download page: I think you need to add the cgi page named download_compress.cgi too. The contents of the file do now depend on the project, and you will find an example in the neighbouring directories, like collections, or configration. The link to the download page has to point to the cgi file, not the html. The cgi file will load the html one and replace the tags. Some of the commons projects seem to put their download pages in the downloads directory (and add them to the index.html there), some seem to prefer to keep it under the project directory. Regards, Rainer - 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: Time for a POOL 1.5 release?
On May 18, 2009, at 4:46 PM, Mark Thomas wrote: Phil Steitz wrote: Mark Thomas wrote: I have finished working my way through the open POOL bugs. Of the remaining issues, 2 are bugs that only affect the 2.0 branch and rest are improvements. Given that Tomcat is waiting on a DBCP release and DBCP is waiting on a POOL release I would like to progress a POOL 1.5 release asap. Does POOL have a usual release manager? If so, do they want to do this release? If not, I'll start working my way through the release procedures. Big +1 for releasing and THANKS for plowing through the backlog of issues. I did the last release and will do this one so you can focus your available cycles on DBCP - unless you are dying to learn the try-as-we-might-will-always-be-a-black-art commons release process. Or unless some other victi...er, I mean volunteer steps up. Thanks for the offer. I must confess I feel no great urge to learn this particular black art ;) That said, if there is anything I can do to help just let me know. Same here... I'll follow what you (Phil) do so we have 2 additional potential RMs - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Rebooting commons projects
On May 18, 2009, at 2:39 AM, Henri Yandell wrote: HttpClient is another example that is complained about by users :) The only saving grace of v4 is that it is now named HttpComponents Core (fitting Stephen's suggestion of a new name). Well, this is kinda appropriate because I really have some ideas and code regarding CLI... 1.0 is used all over, and 1.1 is not so much and yet I personally like 1.1 better (when it works)... My hope is to create a 1.2 which becomes a more recent standard but at the same time not break, as much as possible, people who are using 1.0. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
request for karma
If possible, I'd like karma for commons-sandbox. Also, I will doing some work on cli and dbcp (to start) and if the PMC would like to give me prelim-karma for that as well, that would be appreciated :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CLI] 1.2 [Re: [all] Rebooting commons projects]
On May 18, 2009, at 12:10 PM, Henri Yandell wrote: On Mon, May 18, 2009 at 5:33 AM, Jim Jagielski j...@jagunet.com wrote: On May 18, 2009, at 2:39 AM, Henri Yandell wrote: HttpClient is another example that is complained about by users :) The only saving grace of v4 is that it is now named HttpComponents Core (fitting Stephen's suggestion of a new name). Well, this is kinda appropriate because I really have some ideas and code regarding CLI... 1.0 is used all over, and 1.1 is not so much and yet I personally like 1.1 better (when it works)... My hope is to create a 1.2 which becomes a more recent standard but at the same time not break, as much as possible, people who are using 1.0. We did that :) 1.2 was released in March, undoing the regression issues in 1.1 and other bugfixes: I meant 1.x not 1.2... The kind of gets back to my karma request. Even with 1.2 out, there is still the impression that it's not a well-maintained chunk of code. I just thought having more people involved would help offset that mindset... - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: request for karma
eg: for cli, I find the default help/usage text much too limiting; it would be nice to be able to have that completely under user control with some sort of templating interface. It would also be cool if that could also drive the parser being used (by defining usage formating string, the matching parser is chosen) or even get away from a selection of parsers and just have 1 super parser. Also '- Xxx1024m' should really be added in. For dbcp, it's basically to help 1.3 On May 18, 2009, at 12:08 PM, Henri Yandell wrote: What kind of work are we talking about? ie) What's the sandbox karma for - we're nosy and like to hear about ideas :) For CLI/DBCP - if it's a lot of work then that's a good place to work on things in the sandbox. If rather it's some bugfixes, then best is to attach them as patches to JIRA issues. I generally shepherd CLI currently and Phil generally shepherds DBCP - though any of the committers can apply but it gives you names to hassle if there is no response. Hen On Mon, May 18, 2009 at 6:29 AM, Jim Jagielski j...@apache.org wrote: If possible, I'd like karma for commons-sandbox. Also, I will doing some work on cli and dbcp (to start) and if the PMC would like to give me prelim-karma for that as well, that would be appreciated :) - 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
