Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Fri, 6 Jun 2003 07:46:02 +0100
Subject: Re: [VOTE] New Commiter Phil Steitz
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3EDFC5B7.1080500@latte.harvard.edu>
Message-Id: <8A1C6F68-97EA-11D7-A279-003065DC754C@blueyonder.co.uk>

hi mark

it's pretty much the scenario that you describe that concerns me. phil has 
certainly been the most active member of the commons-math development team 
but commons-math was originate by myself. i'm glad to say that tim joined 
and has done most of the spade work (good work, tim). it's a credit to the 
commons-math community that the contribution by non-committers has been so 
great. this points towards a healthy future for the component.

there are other avenues in apache available for the development of code 
bases - the incubator project or the commons project where the rules and 
aims are different. but commons-math is in the sandbox and we need to be 
careful about remaining within the bounds set.

- robert

On Thursday, June 5, 2003, at 11:35 PM, Mark R. Diggory wrote:

> Robert,
>
> Your viewpoint is warranted and understandable, the motivation for the 
> sandbox is to provide a means to refactor existing projects/fragments 
> into better designed components, As such its fair to see its activity 
> oriented to existing developers. I know I was voted in for both my 
> interest in the Math component project and the past work I've done with 
> Jelly and HttpClient.
>
> But IMHO, this is a unique case that should be reconsidered. Consider the 
> following: a non-commiter reviews a project in the Commons, sees that 
> there are avenues for enhancment or refactoring, and proposes a project 
> to consolidate/enhance those features. This proposal is approved and a 
> new sandbox project is born.  Because the one who proposed the project is 
> not already a commiter, their efforts are diminished during the projects 
> initial development. Thus "limiting" the projects productivity and future 
> development.
>
> I don't believe math started as an independent project, math is the 
> foster child of the lang project, based on decisions about enhancing and 
> giving a home to the math features that are present there. As such, there 
> is a grey area here.  As Phil's basis for proposing was on code in [lang]
>  it possibly seems the responsibility for nominating commit rights falls 
> on the shoulders of that original commons component [lang]. This is based 
> on the discussions about placing math tools in lang that gave rise to the 
> sandbox math development.
>
> Finally, To clarify, my specific reasons for nomination concern the fact 
> that a large amount of "energy pushing this component forwards" is coming 
> from Phil, being he initially proposed the project, isn't it unfair to 
> exclude him from being a member of the team that brings it to maturity?
>
> Long live Jakarta-Commons,
> Mark Diggory
>
>
> robert burrell donkin wrote:
>> i'm sad to do this (since i think that phil's demonstrated the qualities 
>> required and i'd support a nomination when and if math makes it into the 
>> commons proper) but i think that nominating people for contributions to 
>> the sandbox will cause troubles (sooner or later) and also that it's 
>> against the spirit of the common charter.
>> as i understand it, the commons is responsible for supervising the 
>> sandbox,
>>  nothing more. the sandbox is not a subproject in it's own right and 
>> exists only to allow apache developers to collaborate. i believe that 
>> the commons can and should only elect committers for its own components.
>>
>> i also feel that one of the reasons stated by mark for nomination (that 
>> we need him on board to make it to release) is not a good one. we in the 
>> commons are charged by the ASF with supervising the sandbox. if there is 
>> insufficient energy to push a component forwards then there will be 
>> insufficient energy to properly supervise new committers.
>
>> i'd like to ask the math developers for a little patience. i'm convinced 
>> that commons-math has a bright future but it will take a little time. i 
>> also hope that phil doesn't take this personally (this isn't anything 
>> against him personally but against the principle of nominating new 
>> non-apache committers for sandbox components).
>> -1
>> - robert
>> On Thursday, June 5, 2003, at 02:39 PM, Mark R. Diggory wrote:
>>> I'm not sure if I have enough rights yet to nominate Phil Steitz for 
>>> commiter (I just became a commiter myself). Phil is the initial 
>>> proposal author on the math project. That in and of itself should be 
>>> enough to warrant his inclusion. Phil has been supplying many patches 
>>> and is now considering development of the "complex number" architecture 
>>> for the package. I think he would make an excellent commiter as he has 
>>> done a great deal of work via patches to clarify the coding, testing 
>>> and documentation standards for the math project. We *need* him to have 
>>> commit rights on this project before we can make it to release.
>>>
>>> +1
>>>
>>> Mark Diggory
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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