[jira] Commented: (JXPATH-92) Allow to use NodePointers as variable values and preserve tree position information
[ https://issues.apache.org/jira/browse/JXPATH-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510860 ] Sergey Vladimirov commented on JXPATH-92: - Okay, Matt. Seems i will need to suppor this functionality in our own patched version of jxpath only. We need such functionality in our implementation of XSLT transformer, and i can hardly see how to dynamically build XPath expressions in this case - it's user desicion whether to use variables or not. Anyway, thank you for time spent on this issue. This was the last one, now i'm waiting for the stable build :) Allow to use NodePointers as variable values and preserve tree position information --- Key: JXPATH-92 URL: https://issues.apache.org/jira/browse/JXPATH-92 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Reporter: Sergey Vladimirov Attachments: hack-patch.txt, VariablePointerTestCase.java Moved from JXPATH-89 It should be possible to return NodePointer as variable value and use such node pointer as part of original tree to sort and comapre nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r554172 - /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Author: ozeigermann
Date: Sat Jul 7 02:51:44 2007
New Revision: 554172
URL: http://svn.apache.org/viewvc?view=revrev=554172
Log:
Added patch that now deletes dangling links.
Patch provided by Bojan Vukojevic
Details can be found here: https://issues.apache.org/jira/browse/TRANSACTION-19
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java?view=diffrev=554172r1=554171r2=554172
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Sat Jul 7 02:51:44 2007
@@ -157,7 +157,10 @@
throw new IOException(Could not delete file +
removeFile.getName()
+ in directory targetDir);
}
-}
+} else if (!targetFile.isFile()) {
+// this is likely a dangling link
+targetFile.delete();
+}
// indicate, this has been done
removeFile.delete();
} else {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TRANSACTION-19) applyDeletes method does not delete dangling links
[
https://issues.apache.org/jira/browse/TRANSACTION-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Zeigermann resolved TRANSACTION-19.
--
Resolution: Fixed
OK. Got that now. Thanks for the patch, it has been applied!
Oliver
applyDeletes method does not delete dangling links
--
Key: TRANSACTION-19
URL: https://issues.apache.org/jira/browse/TRANSACTION-19
Project: Commons Transaction
Issue Type: Bug
Affects Versions: 1.2
Environment: Linux CentOS, Java 1.5
Reporter: Bojan Vukojevic
Assignee: Oliver Zeigermann
applyDeletes method will not delete any dangling links. Even if the link was
valid, code may run into this situation if the file is passed to be deleted
before link is registered for deletion. Code will delete the file
effectivelly creating a dangling link that will not be deleted.
The fix might be another change to applyDeletes method i.e. something like:
protected static void applyDeletes(File removeDir, File targetDir, File
rootDir) throws IOException {
if (removeDir.isDirectory() targetDir.isDirectory()) {
File[] files = removeDir.listFiles();
for (int i = 0; i files.length; i++) {
File removeFile = files[i];
File targetFile = new File(targetDir, removeFile.getName());
if (!removeFile.isDirectory()) {
if (targetFile.exists()) {
if (!targetFile.delete()) {
throw new IOException(Could not delete file +
removeFile.getName()
+ in directory targetDir);
}
} else if(!targetFile.isFile()){ // CHANGE
to delete dangling link=
//this is likely a dangling link
targetFile.delete();
}
// indicate, this has been done
removeFile.delete();
} else {
applyDeletes(removeFile, targetFile, rootDir);
}
// delete empty target directories, except root dir
if (!targetDir.equals(rootDir) targetDir.list().length ==
0) {
targetDir.delete();
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r554209 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
Author: oheger
Date: Sat Jul 7 07:09:12 2007
New Revision: 554209
URL: http://svn.apache.org/viewvc?view=revrev=554209
Log:
Added a test case for variable interpolation and escaping after a report on the
user list
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java?view=diffrev=554209r1=554208r2=554209
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
Sat Jul 7 07:09:12 2007
@@ -61,6 +61,24 @@
}
/**
+ * Tests escaping the variable marker, so that no interpolation will be
+ * performed.
+ */
+public void testInterpolateEscape()
+{
+AbstractConfiguration config = new TestConfigurationImpl(
+new PropertiesConfiguration());
+config
+.addProperty(
+mypath,
+
$${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar\\,$${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cu.jar);
+assertEquals(
+Wrong interpolated value,
+
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar,${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cu.jar,
+config.getString(mypath));
+}
+
+/**
* A test configuration implementation. This implementation inherits
* directly from AbstractConfiguration. For implementing the required
* functionality another implementation of AbstractConfiguration is used;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510903
]
Oliver Heger commented on CONFIGURATION-284:
Joerg, I think this is a misunderstanding: This feature request is about
environment variables, while Configuration so far only supports Java's system
properties.
I had a vague memory that the topic access to environment variables was
discussed before on the commons mailing list, and found this reference:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325
Obviously this thread did not come to a final solution, AFAIK this feature was
not added to one of the commons libraries. If it was (for instance in
commons-lang), it would be really easy to incorporate it into
commons-configuration. But having to implement it ourselves, situation looks
different. The problem I see here is that it will really be difficult to
implement a robust and portable solution, and besides this feature is probably
out of scope for commons-configuration.
From Java 1.5 on, access to environment properties will be possible using
methods of the System class. So when we switch to this version (no idea when
this will happen though) it will be no problem to satisfy this request. But
for the moment I am reluctant.
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
+1 Phil On 7/4/07, Henri Yandell [EMAIL PROTECTED] wrote: I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-272) ConfigurationUtils.copy results in escaped , characters no longer being escaped
[ https://issues.apache.org/jira/browse/CONFIGURATION-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510904 ] Oliver Heger commented on CONFIGURATION-272: I think the problem here is that ConfigurationUtils operates on plain Configuration objects and does not know about specifics like list delimiters available only for classes derived from AbstractConfiguration. And performing a cast to AbstractConfiguration in these methods would be really ugly IMO. A solution would be to add new copy() and append() methods to AbstractConfiguration with the same semantics. Then we had full control over the copy process and could also determine, which events to generate (maybe it does not make sense to trigger an event for each copied property, but only one event for the whole copy operation). copy() and append() in ConfigurationUtils could then be deprecated, or at least a remark could be added to their documentation that the variants implemented by AbstractConfiguration are preferable. ConfigurationUtils.copy results in escaped , characters no longer being escaped - Key: CONFIGURATION-272 URL: https://issues.apache.org/jira/browse/CONFIGURATION-272 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: commons 1.4 Reporter: John Meagher Assignee: Emmanuel Bourg Fix For: 1.5 When using ConfigurationUtils.copy to go between configuration formats any escaped out , characters are put into the output configuration without the escape character. This results in a different value being returned from getString calls as it now things the property is a list. If 4 escape characters are used instead of the expected 1 then the copy will end up with the correct value, but then the original will end up with the escape character as part of the property value. Example: SomeLongProperty=This is a test\, it is only a test # Ends up right in the copy, but not right in the original SomeOtherProperty=This is also a test, it is also only a test After copy: # Missing \ before , SomeLongProperty=This is a test, it is only a test SomeOtherProperty=This is also a test\, it is also only a test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] Re: issue
If this relates to an open issue against [vfs], you should add your comments to the JIRA ticket for the issue. If you have looked at the open issues and this looks like a new problem, please open a new ticket. To find or create issues against [vfs], follow this link: http://jakarta.apache.org/commons/vfs/issue-tracking.html Also, when posting to this list, you should prepend the component name to the subject line as I have done above. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r554220 - /jakarta/commons/proper/math/trunk/project.xml
Author: psteitz Date: Sat Jul 7 08:36:23 2007 New Revision: 554220 URL: http://svn.apache.org/viewvc?view=revrev=554220 Log: Added recent contributors. Modified: jakarta/commons/proper/math/trunk/project.xml Modified: jakarta/commons/proper/math/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/project.xml?view=diffrev=554220r1=554219r2=554220 == --- jakarta/commons/proper/math/trunk/project.xml (original) +++ jakarta/commons/proper/math/trunk/project.xml Sat Jul 7 08:36:23 2007 @@ -162,10 +162,16 @@ nameRodrigo di Lorenzo Lopes/name /contributor contributor + nameHasan Diwan/name +/contributor +contributor nameKen Geis/name /contributor contributor nameElliotte Rusty Harold/name +/contributor +contributor + nameMatthias Hummel/name /contributor contributor namePiotr Kochanski/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-167) ConvergenceException in normal CDF
[ https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510905 ] Phil Steitz commented on MATH-167: -- Thanks for reporting this. I see three alternatives to address - appreciate comments. 1) Determine tail resolution possible with current impl (hopefully not different on different JDKs, platforms) and top code, checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean. To find the cut points, empirically determine where convergence starts to fail. Document the cut points in javadoc for Impl. 2) Catch ConvergenceException and return 0 or 1, resp if argument is far from the mean; rethrow otherwise (though this should never happen). 3) Resolve as WONTFIX and leave it to client to catch and handle ConvergenceException, examining argument. Document algorithm more fully and warn that ConvergenceException will be thrown if tail probability cannot be accurately estimated or distinguished from 0. My first thought was 2 and I guess I still favor that, since 3) is inconvenient for users and 1) may not be stable unless cut points are conservative. Note that this same problem may apply to tail probablilities of other continuous distributions and we should check and address all of these before resolving this issue. ConvergenceException in normal CDF -- Key: MATH-167 URL: https://issues.apache.org/jira/browse/MATH-167 Project: Commons Math Issue Type: Bug Reporter: Mikko Kauppila Priority: Minor NormalDistributionImpl::cumulativeProbability(double x) throws ConvergenceException if x deviates too much from the mean. For example, when x=+/-100, mean=0, sd=1. Of course the value of the CDF is hard to evaluate in these cases, but effectively it should be either zero or one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
On 7/4/07, Henri Yandell [EMAIL PROTECTED] wrote: snip/ [X] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and snap/ Sorry about that. -Rahul my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Managed Connection support
On 7/6/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote: Thanks, Dain. I applied the patch. I also patched the m1 and ant builds to work. The Ant now fails with JDK 1.3, but unless someone screams loudly soon, we have moved the minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so this is not an issue. Sweet! That was very fast. snip/ For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. I am ambivalent on the merging into existing packages, but we should talk about this. We can figure that out as we get close to a release. If the thing isn't fully tested by then we could just mark the whole package as experimental. Thats what I was thinking, so good to leave as is for now. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. That would be greatly appreciated. We really need [dbcp] and [pool] volunteers. Given that you are an ASF committer, all you have to do is ask to get commons karma and you are certainly welcome to do that :) Excellent, I definitely like access, so I can fix any bugs in the code directly. Looks like there's a little beaurocracy to go through here, but pls keep the patches coming for now. In [dbcp] 1.3, we can fix the close semantics and other things that involve semantic changes. All suggestions and patches are welcome. I'll take a look at it when I get back in town next week. Thanks in advance. You will find that some of these bugs relate to [pool] and fixes need to either be mindful of current pool impl - most importantly the fact that the core of pool is an idle object linked list and there is no guard to protect against the same object appearing multiple times in the list, which will happen if it is returned twice, resulting in serious badness for dbcp - or we need to do something with pool to keep the changes safe. There is an alternative pool impl in the compositepool package in pool head, but the current plan is to push out one more patch release of pool and have dbcp 1.3 continue to use the GenericObjectPool. See roadmap discussion here: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg94027.html Comments welcome! Since POOL-97 is causing app server issues, it would be great to get some feedback on the proposed fix there and then bundle up a pool 1.3.1 patch release. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r554224 - /jakarta/commons/proper/math/trunk/pom.xml
Author: psteitz Date: Sat Jul 7 09:17:34 2007 New Revision: 554224 URL: http://svn.apache.org/viewvc?view=revrev=554224 Log: Added recent contributors - should have been in r554220. Modified: jakarta/commons/proper/math/trunk/pom.xml Modified: jakarta/commons/proper/math/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/pom.xml?view=diffrev=554224r1=554223r2=554224 == --- jakarta/commons/proper/math/trunk/pom.xml (original) +++ jakarta/commons/proper/math/trunk/pom.xml Sat Jul 7 09:17:34 2007 @@ -104,10 +104,16 @@ nameRodrigo di Lorenzo Lopes/name /contributor contributor + nameHasan Diwan/name +/contributor +contributor nameKen Geis/name /contributor contributor nameElliotte Rusty Harold/name +/contributor +contributor + nameMatthias Hummel/name /contributor contributor namePiotr Kochanski/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-167) ConvergenceException in normal CDF
Phil Steitz (JIRA) wrote: [ https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510905 ] Phil Steitz commented on MATH-167: -- Thanks for reporting this. I see three alternatives to address - appreciate comments. 1) Determine tail resolution possible with current impl (hopefully not different on different JDKs, platforms) and top code, checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean. To find the cut points, empirically determine where convergence starts to fail. Document the cut points in javadoc for Impl. 2) Catch ConvergenceException and return 0 or 1, resp if argument is far from the mean; rethrow otherwise (though this should never happen). 3) Resolve as WONTFIX and leave it to client to catch and handle ConvergenceException, examining argument. Document algorithm more fully and warn that ConvergenceException will be thrown if tail probability cannot be accurately estimated or distinguished from 0. My first thought was 2 and I guess I still favor that, since 3) is inconvenient for users and 1) may not be stable unless cut points are conservative. Note that this same problem may apply to tail probablilities of other continuous distributions and we should check and address all of these before resolving this issue. I also think 2) is the better choice. I don't think finding the cut point for 1) is even feasible reliably for all JVM implementations, so 2) as the advantage of being self-adaptive. Another reason I like this is that this is really an exceptional case so exceptions are really suited to that, they should not be restricted to error handling only. Using them here is probably more efficient as it saves two a priori if statements that are really not needed most of the time. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-167) ConvergenceException in normal CDF
I think (2) may be simplest and best I dont really think that throwing an exception here is appropriate at all. It mat be possible however, to determine the resolution as you suggest in (1). I'm not sure what packages like R do internally currently. pnorm(-100) [1] 0 pnorm(100) [1] 1 Rory Phil Steitz (JIRA) wrote: [ https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510905 ] Phil Steitz commented on MATH-167: -- Thanks for reporting this. I see three alternatives to address - appreciate comments. 1) Determine tail resolution possible with current impl (hopefully not different on different JDKs, platforms) and top code, checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean. To find the cut points, empirically determine where convergence starts to fail. Document the cut points in javadoc for Impl. 2) Catch ConvergenceException and return 0 or 1, resp if argument is far from the mean; rethrow otherwise (though this should never happen). 3) Resolve as WONTFIX and leave it to client to catch and handle ConvergenceException, examining argument. Document algorithm more fully and warn that ConvergenceException will be thrown if tail probability cannot be accurately estimated or distinguished from 0. My first thought was 2 and I guess I still favor that, since 3) is inconvenient for users and 1) may not be stable unless cut points are conservative. Note that this same problem may apply to tail probablilities of other continuous distributions and we should check and address all of these before resolving this issue. ConvergenceException in normal CDF -- Key: MATH-167 URL: https://issues.apache.org/jira/browse/MATH-167 Project: Commons Math Issue Type: Bug Reporter: Mikko Kauppila Priority: Minor NormalDistributionImpl::cumulativeProbability(double x) throws ConvergenceException if x deviates too much from the mean. For example, when x=+/-100, mean=0, sd=1. Of course the value of the CDF is hard to evaluate in these cases, but effectively it should be either zero or one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-232) Add script attribute to control script generation
Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n
On 7/6/07, Phil Steitz [EMAIL PROTECTED] wrote: So my proposal is that any ASF committer who wishes to become a commons committer just needs to make that request here on the commons-dev mailing list and they will granted karma for both commons proper and commons sandbox. Expectation is of course that ASF committers joining the commons will behave (http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette). Obviously I'm +1 on making it easier. As far as behaving - the solution is that the quiet majority have to step up and yell if someone is being a rude . We've a bit of a technical issue on it; it's quite easy to show up and if a component is in a lull, to charge in and make sweeping changes. The release is a point where we can nip that in the bud, but that's a long time after lots of work. So I think something I would be looking for when someone wants to hop in is that there is an active commons committer managing the component they're about to commit to. Other than that, I believe in as open a door as possible. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
