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 2004/12/26 17:48:06 UTC

Dormancy worries

(Along with SVN prodding, I'm going to look into our dead zones this 
quarter)


JServ, Watchdog and Alexandria are both dormant as far as I know. The 
mailing list for Alexandria needs to be closed down, so I'll take care of 
making that happen.

BCEL and BSF both seem to be in danger of having no actual Apache 
community, just a user community which we are hosting. It may be that 
Christmas is interfering, so I'll be looking to find evidence that these 
communities are healthy this quarter. My gut feel is that they're 
unhealthy, or very close to unhealthy.

ORO and Regexp also are low, but I'm confident that both have an Apache 
commiter actively monitoring the community. ORO-User's archive seems dead, 
so need to fix that. Many of the user requests to Regexp are to do with 
regular expressions and not the library, so I wonder just how much overlap 
there is with the ORO-User list.

ECS is another that I'm confident is being somewhat monitored. The ECS-dev 
archive looks to be dead, so need to fix that. ECS is definitely one that 
I wonder if the Commons community could be supporting; guess I need to 
look at the code as my only worry would be that it's too large a codebase 
to try to jam in.


Apologies if I've misrepresented a part of our community here. It's my 
first take on the situation and I'm sure it will adjust over the next few 
weeks. What we do when we decide that a subproject is dormant will be up 
to this list, the first step is to recognise our current state.


Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Sun, 2004-12-26 at 11:48 -0500, Henri Yandell wrote:
> ECS is another that I'm confident is being somewhat monitored. The ECS-dev 
> archive looks to be dead, so need to fix that. ECS is definitely one that 
> I wonder if the Commons community could be supporting; guess I need to 
> look at the code as my only worry would be that it's too large a codebase 
> to try to jam in.

I'm watching ECS.

	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

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
              -- actual question from a Microsoft customer survey


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by Mark Thomas <me...@virgin.net>.
Henri Yandell wrote:
> JServ, Watchdog and Alexandria are both dormant as far as I know. The 
> mailing list for Alexandria needs to be closed down, so I'll take care 
> of making that happen.

Depends how you define dormant. There is _very_ occasional use of 
Watchdog when we do a Tomcat 4 release. This is itself a pretty rare 
event but I can see there being at least one further Tomcat 4 release.

I don't see Tomact 4's use of Watchdog being a sufficient driver for 
further commits to the Watchdog codebase.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by Mark Thomas <ma...@apache.org>.
Henri Yandell wrote:
> JServ, Watchdog and Alexandria are both dormant as far as I know. The 
> mailing list for Alexandria needs to be closed down, so I'll take care 
> of making that happen.

Depends how you define dormant. There is _very_ occasional use of 
Watchdog when we do a Tomcat 4 release. This is itself a pretty rare 
event but I can see there being at least one further Tomcat 4 release.

I don't see Tomact 4's use of Watchdog being a sufficient driver for 
further commits to the Watchdog codebase.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 1 Jan 2005, at 12:58, Henri Yandell wrote:
> On Sat, 1 Jan 2005, robert burrell donkin wrote:
>> On 1 Jan 2005, at 11:52, Henri Yandell wrote:
>>> On Sat, 1 Jan 2005, robert burrell donkin wrote:

<snip>

>>> So how should we do it under the assumption that everyone doesn't up 
>>> for TLP? Do we add a jakarta-user and jakarta-dev mailing list that 
>>> is the merger of N sub-projects and effectively another Commons, or 
>>> just kill the N mailing-lists in favour of the commons lists and 
>>> give CVS access to Commons committers to the N sub-projects?
>>
>> the commons started out as an experiment. why not just start a new 
>> experiment?
>>
>> the new experiment would not be a sub-project and not have any 
>> sub-project layer (in organizational terms). the only binding votes 
>> would be from jakarta pmc'ers and karma would be granted (upon 
>> request) to any jakarta committer who wished to contribute (by means 
>> of a status file).
>
> I'm not sure what this consists of apart from adding a Components 
> section to the nav section and putting a few things under it instead 
> of Subprojects. Would we change the SVN structure in anyway? What 
> actually would change? Just commit perms?

the major change would be organizational: they would no longer be 
sub-projects but products directly managed by the jakarta project. in 
practical terms, the major change noticable would be that any necessary 
VOTEs would happen on the pmc and all jakarta committers would be 
treated equally (karma granted on request). the rest could remain the 
same.

i would personally favour moving away from the division into 
sub-projects on the navigation bar into something more suitable as a 
directory or portal.

<snip>

>> i don't know how this will all work out in the longer term but it's 
>> closer to the preferred model than the mature sub-projects are now 
>> and so is a step in the right direction. maybe a little further along 
>> the process it'll be easier to see the best way forward from where we 
>> are then.
>
> I'm always in favour of ways to take baby steps to good long term 
> goals, but not sure what the steps would change here.
>
> If, say, we change commit rights to BCEL, BSF, ECS, ORO and Regexp to 
> any Jakarta committer, they'd still only be changed by people 
> listening to the mail lists. If we offer commit to any Jakarta 
> committer who asks, I suspect no one would ask.

most of these projects are mature with few reasons for further 
development. it is possible that with more liberal commit rights, one 
or two may come alive again but i'd say that the main motivation should 
be to provide an effective maintenance environment for mature code.

all of these have experienced issues with the sub-project organization 
model (since they have too few active sub-project committers to form a 
quorum). the products-within-project may turn out to be a better model.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by Henri Yandell <ba...@generationjava.com>.

On Sat, 1 Jan 2005, robert burrell donkin wrote:

>
> On 1 Jan 2005, at 11:52, Henri Yandell wrote:
>
>> 
>> 
>> On Sat, 1 Jan 2005, robert burrell donkin wrote:
>> 
>>> On 27 Dec 2004, at 11:35, Torsten Curdt wrote:
>>>> Noel J. Bergman wrote:
>>> 
>>> <snip>
>>> 
>>>>> There has been
>>>>> some suggestion that they be cleaned up by migrating them to some other
>>>>> domain to be mothballed.  The code, web site, and mailing list archives
>>>>> would be preserved, and could be restored at such time in the future 
>>>>> when a
>>>>> community might arise.
>>>> Hmm... the question is whether we really *can* mothballing them.
>>>> IMHO too many projects rely on them. It's an important piece of
>>>> technology. At least bugfixes need to be applied. FWICS migration
>>>> costs (e.g. to asm) are fairly high.
>>>> There *are* people that have patches in the queue.
>>> 
>>> i would like to suggest again something that costin suggested a long while 
>>> ago now: for mature sub-projects we remove the extra layer and organize 
>>> them directly under jakarta. so rather than being run as sub-projects with 
>>> their own separate committer lists, the jakarta community runs them 
>>> directly.
>> 
>> Effectively I'm +1 on that. I think of it as hope that enough of the 
>> self-contained projects ask to move to TLP and then we promote Commons 
>> components to sub-project level and make CVS Jakarta-wide.
>
> i'm not sure that moving commons components to sub-project level would be a 
> good idea. IMHO it would be far better to leave them exactly as they 
> currently are: components distributed by jakarta. i can see no benefits from 
> designating them as sub-projects. even the name has become more than a little 
> tainted.

Well, the impossible dream runs:

1) Various things goto TLP.
2) We're left with Commons, various component like subprojects 
(ORO/Regexp/ECS etc)
3) Promote Commons components to Jakarta level
4) Rename Subprojects to Components

>> So how should we do it under the assumption that everyone doesn't up for 
>> TLP? Do we add a jakarta-user and jakarta-dev mailing list that is the 
>> merger of N sub-projects and effectively another Commons, or just kill the 
>> N mailing-lists in favour of the commons lists and give CVS access to 
>> Commons committers to the N sub-projects?
>
> the commons started out as an experiment. why not just start a new 
> experiment?
>
> the new experiment would not be a sub-project and not have any sub-project 
> layer (in organizational terms). the only binding votes would be from jakarta 
> pmc'ers and karma would be granted (upon request) to any jakarta committer 
> who wished to contribute (by means of a status file).

I'm not sure what this consists of apart from adding a Components section 
to the nav section and putting a few things under it instead of 
Subprojects. Would we change the SVN structure in anyway? What actually 
would change? Just commit perms?

> i'd say leave the mailing lists for now (there are infrastructure 
> implications) but let's give the mature sub-projects you listed earlier a 
> choice: join the new experimental not-sub-project or move to TLP status.

Not a choice I can give. I can dream of TLPness, but as far as I know the 
community does not want to be pushing to TLPness.

Interestingly, time is working against us. If we view TLP-ers as liberal 
and Jakarta-ers as conservative (not politically, just in approach to the 
idea of location), then as time goes by the community is more and more 
against pushing for TLP :)

> i don't know how this will all work out in the longer term but it's closer to 
> the preferred model than the mature sub-projects are now and so is a step in 
> the right direction. maybe a little further along the process it'll be easier 
> to see the best way forward from where we are then.

I'm always in favour of ways to take baby steps to good long term goals, 
but not sure what the steps would change here.

If, say, we change commit rights to BCEL, BSF, ECS, ORO and Regexp to any 
Jakarta committer, they'd still only be changed by people listening to the 
mail lists. If we offer commit to any Jakarta committer who asks, I 
suspect no one would ask.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 1 Jan 2005, at 11:52, Henri Yandell wrote:

>
>
> On Sat, 1 Jan 2005, robert burrell donkin wrote:
>
>> On 27 Dec 2004, at 11:35, Torsten Curdt wrote:
>>> Noel J. Bergman wrote:
>>
>> <snip>
>>
>>>> There has been
>>>> some suggestion that they be cleaned up by migrating them to some 
>>>> other
>>>> domain to be mothballed.  The code, web site, and mailing list 
>>>> archives
>>>> would be preserved, and could be restored at such time in the 
>>>> future when a
>>>> community might arise.
>>> Hmm... the question is whether we really *can* mothballing them.
>>> IMHO too many projects rely on them. It's an important piece of
>>> technology. At least bugfixes need to be applied. FWICS migration
>>> costs (e.g. to asm) are fairly high.
>>> There *are* people that have patches in the queue.
>>
>> i would like to suggest again something that costin suggested a long 
>> while ago now: for mature sub-projects we remove the extra layer and 
>> organize them directly under jakarta. so rather than being run as 
>> sub-projects with their own separate committer lists, the jakarta 
>> community runs them directly.
>
> Effectively I'm +1 on that. I think of it as hope that enough of the 
> self-contained projects ask to move to TLP and then we promote Commons 
> components to sub-project level and make CVS Jakarta-wide.

i'm not sure that moving commons components to sub-project level would 
be a good idea. IMHO it would be far better to leave them exactly as 
they currently are: components distributed by jakarta. i can see no 
benefits from designating them as sub-projects. even the name has 
become more than a little tainted.

> Suggestions that they move into Commons is effectively an attempt to 
> get this community feature.

yeh, thought that might be the case :)

commons seems to be working ok now and IMHO it'd be better to leave it 
alone...

> So how should we do it under the assumption that everyone doesn't up 
> for TLP? Do we add a jakarta-user and jakarta-dev mailing list that is 
> the merger of N sub-projects and effectively another Commons, or just 
> kill the N mailing-lists in favour of the commons lists and give CVS 
> access to Commons committers to the N sub-projects?

the commons started out as an experiment. why not just start a new 
experiment?

the new experiment would not be a sub-project and not have any 
sub-project layer (in organizational terms). the only binding votes 
would be from jakarta pmc'ers and karma would be granted (upon request) 
to any jakarta committer who wished to contribute (by means of a status 
file).

i'd say leave the mailing lists for now (there are infrastructure 
implications) but let's give the mature sub-projects you listed earlier 
a choice: join the new experimental not-sub-project or move to TLP 
status.

i don't know how this will all work out in the longer term but it's 
closer to the preferred model than the mature sub-projects are now and 
so is a step in the right direction. maybe a little further along the 
process it'll be easier to see the best way forward from where we are 
then.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by Henri Yandell <ba...@generationjava.com>.

On Sat, 1 Jan 2005, robert burrell donkin wrote:

> On 27 Dec 2004, at 11:35, Torsten Curdt wrote:
>> Noel J. Bergman wrote:
>
> <snip>
>
>>> There has been
>>> some suggestion that they be cleaned up by migrating them to some other
>>> domain to be mothballed.  The code, web site, and mailing list archives
>>> would be preserved, and could be restored at such time in the future when 
>>> a
>>> community might arise.
>> 
>> Hmm... the question is whether we really *can* mothballing them.
>> IMHO too many projects rely on them. It's an important piece of
>> technology. At least bugfixes need to be applied. FWICS migration
>> costs (e.g. to asm) are fairly high.
>> 
>> There *are* people that have patches in the queue.
>
> i would like to suggest again something that costin suggested a long while 
> ago now: for mature sub-projects we remove the extra layer and organize them 
> directly under jakarta. so rather than being run as sub-projects with their 
> own separate committer lists, the jakarta community runs them directly.

Effectively I'm +1 on that. I think of it as hope that enough of the 
self-contained projects ask to move to TLP and then we promote Commons 
components to sub-project level and make CVS Jakarta-wide.

Suggestions that they move into Commons is effectively an attempt to get 
this community feature.

So how should we do it under the assumption that everyone doesn't up for 
TLP? Do we add a jakarta-user and jakarta-dev mailing list that is the 
merger of N sub-projects and effectively another Commons, or just kill the 
N mailing-lists in favour of the commons lists and give CVS access to 
Commons committers to the N sub-projects?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 27 Dec 2004, at 11:35, Torsten Curdt wrote:
> Noel J. Bergman wrote:

<snip>

>> There has been
>> some suggestion that they be cleaned up by migrating them to some 
>> other
>> domain to be mothballed.  The code, web site, and mailing list 
>> archives
>> would be preserved, and could be restored at such time in the future 
>> when a
>> community might arise.
>
> Hmm... the question is whether we really *can* mothballing them.
> IMHO too many projects rely on them. It's an important piece of
> technology. At least bugfixes need to be applied. FWICS migration
> costs (e.g. to asm) are fairly high.
>
> There *are* people that have patches in the queue.

i would like to suggest again something that costin suggested a long 
while ago now: for mature sub-projects we remove the extra layer and 
organize them directly under jakarta. so rather than being run as 
sub-projects with their own separate committer lists, the jakarta 
community runs them directly.

the commons uses an honour system (the committers for the components 
are listed in a STATUS file) which i think would work well in this 
case, with any interested committer being granted karma upon request 
(technically lazy vote of the pmc) and any required VOTEs (which should 
not be many) being done directly by the pmc.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: Dormancy worries

Posted by Torsten Curdt <tc...@apache.org>.
Noel J. Bergman wrote:
> I share your concerns.

Same here! ...there was a poll about how many
active committers are around on bcel-dev.
IIRC *one* responded. Other than that there
are just users around waiting for patches being
applied or just lurking.

http://marc.theaimsgroup.com/?l=bcel-dev&m=110294999712414&w=2

> The general question is what to do with such
> projects, and I think we should be open to creative ideas.

The question is whether those projects
maybe missed to nominate some more committers?

...maybe it would be worth looking into the
patch queue? Not applying patches is also
one way to make people go away.

> There has been
> some suggestion that they be cleaned up by migrating them to some other
> domain to be mothballed.  The code, web site, and mailing list archives
> would be preserved, and could be restored at such time in the future when a
> community might arise.

Hmm... the question is whether we really *can* mothballing them.
IMHO too many projects rely on them. It's an important piece of
technology. At least bugfixes need to be applied. FWICS migration
costs (e.g. to asm) are fairly high.

There *are* people that have patches in the queue.

>>BCEL and BSF both seem to be in danger of having no actual Apache
 >>community

I only know about BCEL ...but that's for sure a danger I see too!

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


RE: Dormancy worries

Posted by "Noel J. Bergman" <no...@devtech.com>.
I share your concerns.  The general question is what to do with such
projects, and I think we should be open to creative ideas.  There has been
some suggestion that they be cleaned up by migrating them to some other
domain to be mothballed.  The code, web site, and mailing list archives
would be preserved, and could be restored at such time in the future when a
community might arise.

> BCEL and BSF both seem to be in danger of having no actual Apache
community

I am a fan of BSF, and would like to see that thrive.  We are making some
use of it in JAMES, which I expect will expand; have proposed use of it in
the Directory server; and I would like to see other projects, e.g.,
Geronimo, avail themselves of BSF.

> ORO and Regexp also are low, but I'm confident that both have an Apache
> commiter actively monitoring the community.

The suggestion has been made to merge both into Jakarta Commons.  I believe
that both are still in fairly widespread use, despite J2SE 1.4 adding
regular expressions to the core library.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org