You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <ba...@apache.org> on 2005/08/09 23:53:13 UTC
Jakarta - Cleaning house
We're getting in a bit of a half-finished state with regards to location
of things etc. Here's my list of things that it seems we need to get
done. Nice and aggressive to cause consternation:
Finish moving Tomcat to TLP
Propose Slide to TLP
Move Commons HttpClient to SLP
Move Turbine JCS to SLP (might just be a mail list change now)
Move Taglibs Standard to SLP
Create WebXxx (name to be voted on)
Create a 'Graveyard' for dead projects
Create a 'Freezer' for stable projects
Kill Taglibs in favour of WebXxx
Aggressively clean Commons Sandbox
Finish SVN migrations (Turbine-3, POI, JMeter, Cactus)
Graveyarding of Alexandria
Freezing of ECS, ORO, Regexp.
BCEL/BSF challenged to show they shouldn't be considered frozen.
Work on policies for how to spot freezing/graveyard targets; BUT don't
wait on this to create them
Additionally I'd like to propose:
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).
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.
Any thoughts?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2005-08-09 at 17:53 -0400, Henri Yandell wrote:
> BCEL/BSF challenged to show they shouldn't be considered frozen.
> Work on policies for how to spot freezing/graveyard targets; BUT don't
> wait on this to create them
Dave Brosius has been reasonably active on BCEL recently. There might be
a bugfix release coming out in the not to distant future.
Long-term I suspect that it is still unlikely to gain new features (esp.
java5.x features which are really needed for the project to survive).
However given Dave's good work I suggest it qualifies as "sleepy" rather
than "dead".
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 9 Aug 2005, Phil Steitz wrote:
> Brett Porter wrote:
>> On 8/10/05, Henri Yandell <ba...@apache.org> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Phil Steitz <ph...@steitz.com>.
Brett Porter wrote:
> On 8/10/05, Henri Yandell <ba...@apache.org> 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.
>
>
>>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.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Brett Porter <br...@gmail.com>.
On 8/10/05, Henri Yandell <ba...@apache.org> 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.
> 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 :)
This all sounds pretty good though!
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 10 Aug 2005, Henning Schmiedehausen wrote:
> Hi,
>
> (... to SVN...)
>
> Yep. But I intentionally didn't migrate the dead projects into the
> jakarta/turbine name space because this would be bound to lead to
> confusion and to users seeing this and starting to ask what these trees
> were.
This is all good. On a global-ASF level I'm collating a list of CVS
repositories to archive and they'll all get handled in some unified way.
Adding turbine-3 to that list in a bit.
http://www.apache.org/dev/drafts/subversion-migration-plan.txt
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
Hi,
(... to SVN...)
Yep. But I intentionally didn't migrate the dead projects into the
jakarta/turbine name space because this would be bound to lead to
confusion and to users seeing this and starting to ask what these trees
were.
Once we agreed on a name, we should have repos/asf/<mumble> and the
migrate directly from the CVS there.
No, I don't want to call it "mumble". ;-)
Regards
Henning
On Wed, 2005-08-10 at 08:33 +0200, Torsten Curdt wrote:
> >> Finish SVN migrations (Turbine-3, POI, JMeter, Cactus)
> >>
> >
> > Turbine-3 should go from CVS to the graveyard. No detour through SVN
> > please.
>
> AFAIU (not totally sure) all projects need to migrated to CVS
> by the end of the year because CVS is meant to go away. If we
> want it to be still available we need to migrate it, too.
>
> cheers
> --
> Torsten
>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Torsten Curdt <tc...@apache.org>.
>> Finish SVN migrations (Turbine-3, POI, JMeter, Cactus)
>>
>
> Turbine-3 should go from CVS to the graveyard. No detour through SVN
> please.
AFAIU (not totally sure) all projects need to migrated to CVS
by the end of the year because CVS is meant to go away. If we
want it to be still available we need to migrate it, too.
cheers
--
Torsten
Re: Jakarta - Cleaning house
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Tue, 2005-08-09 at 17:53 -0400, Henri Yandell wrote:
> We're getting in a bit of a half-finished state with regards to location
> of things etc. Here's my list of things that it seems we need to get
> done. Nice and aggressive to cause consternation:
>
>
> Move Turbine JCS to SLP (might just be a mail list change now)
Should be done by now. On http://jakarta.apache.org/jcs/mail-lists.html
they also mention "old mailing list" and the current lists are jcs-dev
and jcs-users @jakarta.
> Create a 'Graveyard' for dead projects
:-)
> Finish SVN migrations (Turbine-3, POI, JMeter, Cactus)
Turbine-3 should go from CVS to the graveyard. No detour through SVN
please.
> 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.
+1
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta - Cleaning house
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Tue, 2005-08-09 at 18:58 -0400, Henri Yandell wrote:
> Something to represent things that are not expected to have any form of
> activity in the future:
>
> Alexandria
> Commons Messenger
> Commons Graph (1, 2)
jakarta-turbine-3/
jakarta-turbine-jyve/
jakarta-turbine-orgami/
jakarta-turbine-tdk/ (from CVS)
turbine/stratum (from SVN)
should go to the "stable" site at some point.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta - Cleaning house
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 9 Aug 2005, Noel J. Bergman wrote:
>> Create a 'Graveyard' for dead projects
>
> Absolutely not. There is no such thing. I might agree to an Apache
> "museum", which has marginally more acceptable semantics.
I'm not tied to any particular names.
Something to represent things that are not expected to have any form of
activity in the future:
Alexandria
Commons Messenger
Commons Graph (1, 2)
and are not believed to have any form of users.
Jakarta Scrapheap; whatever :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta - Cleaning house
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Create a 'Graveyard' for dead projects
Absolutely not. There is no such thing. I might agree to an Apache
"museum", which has marginally more acceptable semantics.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 9 Aug 2005, Yoav Shapira wrote:
> Hola,
> It'd be nice to have a "state of jakarta" wiki page with all this stuff: I
> think much of it is already captured on other pages like the SVN migration
> wiki.
>
>> Create a 'Graveyard' for dead projects
>
> We should start assembling a list of those.
SLPs are easy. Alexandria's the only one.
Then you get Commons components, Turbine modules, Taglibs and probably the
occasional other bit to add.
>> Create a 'Freezer' for stable projects
>
> What goes in this category? Assuming no product is every perfect and
> improvement always possible, and that we are always open to people rejuvenating
> old projects, why not combine the Freezer and the Graveyard into one?
In my proposal the Graveyard is for dead projects. No official stable
release, no users, nothing. All communication would be directed to the
general@jakarta mailing list.
The Freezer is for inactive projects. Would have had releases, probably
been very active at one point in time. The most important thing is that
they would still have a user-base. foo-user@jakarta.apache.org would still
exist but the dev mailing list would be shutdown in favour of
general@jakarta.apache.org. ECS, ORO, Regexp leap to mind. BSF and BCEL
too if their recent activity quietens down too much. Many parts of
Taglibs/Commons too.
As you should all be reading my mind, I can't see why you didn't all know
this already :)
Being able to freeze/unfreeze needs to be a pretty easy step. Like maybe
we would just ask that emails to ecs-dev get automatically forwarded to
general or something, instead of killing the list.
>> 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.
>
> Interesting idea. I'm not sure it would lead to a lot of PMC
> nominations versus just a lot of requests for karma restoration, but I'm
> not opposed to it.
Well, the idea is that once we get all the noise out of the way, it'll be
very easy to see who is not on the pmc. In fact I'll probably arrange the
subversion authorization groups to make that very obvious.
On karma requests, I'm volunteering to take the hit there. I figure it'll
mean a week of getting lots of email to my private address, and then it
would quieten down.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta - Cleaning house
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
It'd be nice to have a "state of jakarta" wiki page with all this stuff: I
think much of it is already captured on other pages like the SVN migration
wiki.
> Finish moving Tomcat to TLP
Remy is on vacation for another 10 days or so, and I will be on vacation
between August 18th and 28th. Unless the other Tomcat committers feel very
energetic while we're gone, I think we'll do the TLP migration early in
September.
> Create a 'Graveyard' for dead projects
We should start assembling a list of those.
> Create a 'Freezer' for stable projects
What goes in this category? Assuming no product is every perfect and
improvement always possible, and that we are always open to people rejuvenating
old projects, why not combine the Freezer and the Graveyard into one?
> 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).
+1.
> 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.
Interesting idea. I'm not sure it would lead to a lot of PMC nominations
versus just a lot of requests for karma restoration, but I'm not opposed to it.
It'll be an interesting social experiment.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org