On Nov 12, 2006, at 1:05 PM, Jacob Kjome wrote:
Maybe its time for new blood? If existing Log4j developers can't put in the time necessary to move things along as fast as the community would like, then it might be time to accept some new developers from the community that are willing to keep things moving. Elias, are you volunteering? Users like Kay Abendroth, who has been extremely busy the last couple days canvassing Bugzilla reports, may be what we need to move things along.Of course, some evidence of providing quality patches and general dedication are prerequisites to becoming a candidate for committer access to the project, as well as having been nominated by a committer (I'm not 100% sure of all the Apache rules for committer access?). Maybe some of the other committers can chime in here. I don't want to start nominating people before we get a consensus of what approach, if any, should be taken.Thoughts? Jake
I've personally been on deadline on a project for the last few weeks, so I know that I have not been as responsive as I would like, but calling the project dead seems unwarranted as we had a release with a lot of bug fixes in October and Jacob Kjome (PMC member and committer) and James Stauffer (contributor) have been stepping up on answering usage questions on the mailing list. The recent flurry of bug reports and bug report changes from Kay Abendroth, while appreciated, is going to take a little while to digest and review even under the best of circumstances. As far as I can tell Kay has not been previously involved with log4j before this month and historically the PMC has declined to vote someone in as a committer unless they have had several months of active involvement.
As for adding new committers, any potential committer will have to agree to the Contributors License Agreement (CLA) found at http:// www.apache.org/licenses. As some people would not feel they would not be able to sign a CLA due to terms of their employment or just a desire to avoid talking to their employer's legal department, I feel that a vote for commit access is not beneficial until it is known whether the potential committer would be willing to sign a CLA. ASF desires CLA's from all contributors of ideas, code or documentation to have executed a CLA which basically means that earning the history to be considered for commit access means that you should have already filed a CLA.
For changes on the 1.2 branch, I don't think things will ever move as fast as some would like since the committers have to be very cautious on what goes into a very mature and widely used library. Hopefully, in that regard the committers are reflect the desires of the silent majority of log4j 1.2 users who don't want their app to fail in new and different ways even if that means it still fails in the old and expected ways. Until recently, the 1.2 branch had been effectively stalled for years. The recent log4j 1.2.14 knocked off 20+ bugs that had all been languishing in Bugzilla for a very long time. There were definitely remaining bugs filed against 1.2 that were not addressed in 1.2.14, however I think that I killed all or at least almost all that were low risk.
log4j 1.3 is much more open to the types of changes that can get checked in. However, I think that the branch is effectively a dead end as it does not address the concurrency issues that are becoming more frequently reported and is not (and likely will never be) a drop in replacement for log4j 1.2.
log4j 2.0 is still just an idea, but my opinion is that it is the most effective use of my personal log4j related development efforts. I hope to get some of the things that we have been talking about for years together in a skeleton form real-soon-now so that we can start working collaboratively.
smime.p7s
Description: S/MIME cryptographic signature
