Re: Dormancy worries

[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

[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

[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

[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