Brett Porter wrote:
I think the solution is easier:
Anyone that proves they are capable will be given access to do this.
We won't be handing out responsibility to volunteers who have not yet
proven they are capable at the task through patches - just like how
commit access is granted in general.
We do need better revision control, and at some point to draw a line in
the sand and not change things. My single biggest regret about the first
release is not sorting this out better, even though I knew it was coming
I thought it would peak and get sorted out. I can't believe we *still*
can't agree on how hibernate should be done. I actually wonder if we'd
been better off starting from scratch and adding lovingly hand-crafted
POMS by people that needed them. I guess there's still time to start
over in a new repo :)
Cheers,
Brett
I personally think an interesting project for someone with time on their
hands would be to write some code to walk the repository and derive
useful facts from the dependency graph. I know this is on Brett's todo
list, but it doesnt actually need repository/CVS access, and could be
written by anyone.
Things you could do with the right tool
-reverse analysis, who uses "junit", or junit-3.7
-cycle detection; who depends on a dependency
-missing artifacts: what depends on things that arent there (split into
sun, OSS, proprietary)
-scale: who depends on the most stuff
-stability: who is most bleeding edge, versus trailing
output: generate fancy SVG graphs from it, or RDF triples for the fun of it.
Having just been doing complex graph work in Java, I'd actually consider
using Prolog for working with the dependency graph; the plugins for java
are usually LGPL or GPL based though, especially the working ones (like
JLog).
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
