Sorry for the delay and my general absence from the discussions. Things are still crazy here at work.
+1
My comments on the subject:
1) If the "sister" projects decide to not particpate, then I think the need/momentum for this TLP dissipates. So, their support is key, in my mind. I think that the work and evangelization that Scott and others have been doing is great, and I would like to see it all come together under a TLP umbrella. I would like to see members from these other projects as part of the final proposal. I don't know what the implications are for licenses or if the sister projects are required to change licenses, etc.
Scott has indeed been doing a really outstanding job. Thank you, Scott!
The question of licenses is an important one. The ASF has rather strict rules about licenses, as it should. All the code distributed by the ASF is done under the Apache Software license. I know of no exceptions to this rule. Negotiating and changing the licensing terms take time.
Thus, while the inclusion of sister project is an important goal, we should not hinge the Logging Services proposal on the acceptance of such and such sister project. Sister project are most most welcome to join but they are not absolutely necessary for the creation of the Logging Services project.
2) I personally see this as a great way to "take out" commons-logging with something that is (maybe) less controversial, better implemented, and has a richer set of features. Exactly what form it will take and whether the community at-large accepts it is a different question. But I think it would be within the bounds of this TLP.
Although there are compelling reasons for using commons-logging, I believe that we do not need to "take it out". Given the tremendous complexity it brings to the game, it will end up "taking out" itself without our help. It is just a matter of time. The unsuspecting people who favor commons-logging do so because it looks good on paper. However, once they are bitten by it, they are bitten so hard and so painfully that their perception changes forever. Some become ardent opponents of commons-logging, some just use log4j, and others JDK 1.4 logging.
As for a better commons-logger, I think any bridging API which is *simpler* will result in a net gain. However, my experience also tells me that abstracting independent APIs performing similar tasks is a major undertaking, much more arduous than one would initially suspect.
Of course, everyone listed in the proposal realizes that there will be added responsibilites being a PLC member, right? You'll be moving up the Apache "chain of command", so to speak. This will be a new PLC, so we'll be setting up shop, setting the project standards, etc. I think it is great and I am looking forward to working with everyone on it.
Well, being TLP will require more formalism, which is not a panacea in itself to say the least.
-Mark
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
