On Tue, 9 Aug 2005, Phil Steitz wrote:
Brett Porter wrote:
On 8/10/05, Henri Yandell <[EMAIL PROTECTED]> wrote:
Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'.
+ All Jakarta committers given access, central management of the sandbox
+ concepts as opposed to individual SLP sandboxes (Taglibs, Commons,
+ Turbine probably has things which could have gone in a sandbox).
I'd be interested to know how this works - I'm not sure unification
brings much to each of them, but it would allow a bit more oversight
by Jakarta as a whole as to each things health.
I am -0 on this, meaning I need to understand more what exactly it will
accomplish and I have a couple of concerns. First I am worried that for j-c-s
in particular, separation from j-c will make it harder for j-c-s projects to
gain critical mass and "graduate" to commons proper.
Second, removed from a "parent" SLC, a sandbox becomes a tricky thing to
provide effective overight for. The mentor and ppmc roles in the Incubator
are there for a reason. I would actually be more concerned about oversight in
an "aggregated" sandbox.
If we can implement the "cleanup" policies that we have been discussing on
commons-dev, I think the j-c sandbox should continue to work fine as it is
and in fact be a model for the other SLPs, each overseeing its own if
desired. As I said, I need to understand better what problem we are trying
to solve here.
Major problems I see:
* Commons Sandbox needs an improvement in policies to deal with the build
up of flotsam. Other sandboxes probably do too, they just don't know it.
Idea would be to handle all these with a single blow.
* Bit below the belt; but promoting Sandbox could give the PMC better
oversight. It tends to hide under Commons I think.
* Jakarta, as a community, is not very ambitious anymore on bringing new
code ideas to the table. James Carman's Syringe project that he wanted to
sandbox somehow (it was outside the Commons scope); the numerous projects
that many of us quite happily start outside of Jakarta (I'll point to my
own stuff at osjava.org as an example there).
As an umbrella, we have an interesting position on new projects. Our
existing subcommunities will spawn off new subcommunities (Hivemind, JCS,
HttpClient, Standard Taglib), but our TLP as a whole has no easy way to
create new SLPs from scratch, unless it be by importing them (Tapestry,
Agila).
Noel will quite rightly point out that the Incubator is for creating new
ASF communities, but the creation of a Jakarta subcommunity is not (imo)
the creation of a new community, it is the result of activity of an
existing community.
My gut is still convincing me as to why I like the idea of having a larger
scoped Sandbox. I feel it'll get us a bit more active, more entwined with
each other, but haven't managed to think it through yet. I'm waffling, but
I think that once we've shed all of our large TLPs, the remainder of
Jakarta needs to become more of a unified community and less of a series
of subcommunities; sharing a Sandbox seems like a strategic stepping
stone.
Just a proto-opinion :)
-
I think you've got a very, very good point though. If it is simply
promoted up, it'll fall through the cracks between the subcommunities.
Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
+ Clean up the very large lists of committers we have in each SLP.
+ Later the jakarta unix group can be sync'd to the SVN jakarta list.
+ Should spur a large-scale nomination of new PMC members.
To save a bit of hassle I think you'll want to start by re-adding
anyone who committed to that project in the last 90 days, otherwise
that's a lot of requests :)
Yes, definitely. Here again, not sure exactly what problem we are trying to
solve.
An easy one to answer; according to /etc/group there are 457 people in
Jakarta. It's a bit harder to get a number from CVS/SVN, but they also
have a rather inflated view of the committers on each project. It's a mess
that needs cleaning.
+1 to Brett's optimisation suggestion. Should be easy to script.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
