incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Date Fri, 11 Dec 2009 17:08:50 GMT
Good points, which we discussed some on the dev@commns list before 
asking the Commons PMC to sponsor this as an Incubator project.

My concerns, were around brining in a new codebase that previously had 
one maintainer, but not offering them committership from the beginning, 
which seemed to follow the normal meritocracy guidelines that most PMCs 
follow.

If everyone feels that creating a podling for this effort is an 
overkill, then I'd be fine going the IP clearance route, as long as the 
existing Apache committers interested in the project are added from the 
start, as there doesn't seem to be a vibrant community around the 
existing Commons Validation project today.


-Donald


Joe Schaefer wrote:
> ----- Original Message ----
> 
>> From: Niall Pemberton <niall.pemberton@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Fri, December 11, 2009 6:29:26 AM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> On Fri, Dec 11, 2009 at 10:42 AM, Joe Schaefer wrote:
>>> ----- Original Message ----
>>>
>>>> From: ant elder 
>>>> To: general@incubator.apache.org
>>>> Sent: Fri, December 11, 2009 5:22:13 AM
>>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>>>
>>>> On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton
>>>> wrote:
>>>>> On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote:
>>>>>> A quick search so there has been some discussion on commons-dev -
[1]
>>>>>>
>>>>>> Does this really need to be incubated - the proposal says its intended
>>>>>> to graduate to Apache Commons and replace the existing Validator
1.x
>>>>>> component as a new 2.0 codebase, from the discussion on commons-dev
>>>>>> everyone seems fine with that out come, and only 2 of the 7 proposed
>>>>>> committers are not existing Validator or ASF committers - so couldn't
>>>>>> this just go straight to commons as a code grant and make the two
new
>>>>>> guys committers in recognition of contibuting the new code?
>>>>> I raised this on private@commons and reported back to dev@commons on
>>>>> that discussion here:
>>>>>
>>>>> http://markmail.org/message/lkyjl6gaxawspgdt
>>>>>
>>>>> In summary though, there was very little support to go that route and
>>>>> some objections.
>>>>>
>>>>> All commons components share the same set of mailing lists which makes
>>>>> it easier for PMC members to provide oversight for the 30+ components
>>>>> that live there. As part of this proposal we want to use the commons
>>>>> mailing lists for commits and discussion so that by the time this
>>>>> podling is ready to graduate the new committers and Commons PMC will
>>>>> have a better knowledge of each other and there will be no issue with
>>>>> voting in the new committers.
>>>>>
>>>>> The use of the commons mailing lists is in the proposal and was part
>>>>> of the vote held on dev@commons to sponsor this incubation effort:
>>>>>
>>>>> http://markmail.org/message/mqdft736b5vasezs
>>>>>
>>>>> Niall
>>>>>
>>>> From the first email referenced was Roman ever asked if he'd mind
>>>> submitting patches for a while to earn Karma if the code did go
>>>> straight to commons? Seems a bit a of a shame to need to go the whole
>>>> incubation process just for one commit access.
>>>>
>>>> Re the the poddling use the existing commons mailing lists its may be
>>>> worth pointing out this recent thread:
>>>> http://apache.markmail.org/message/ifinvq7wqmeoo5ix
>>> Commons is badly busted if it can't allow a new person access to his/her
>>> own code in a fucking sandbox.  Incubating this project because some weenies

>> are
>>> uncomfortable about the nature of the meritocracy over in commons isn't the 
>> solution:
>>
>> Small code bases with small communities are difficult (?almost
>> impossible?) to operate here at the ASF. Commons does OK by providing
>> enough community and oversight to allow 30+ such small components to
>> work here. But it relies on people taking time to keep and eye on
>> components they have no interest in and I didn't want to jeopardize
>> that co-operation by trying to force a decision on the sandbox. Really
>> though, I'm not sure why you're being so abusive over this - is it
>> really a big deal where the code sits in the subversion repository
>> (Commons Sandbox or Incubator)?
> 
> Sorry it's a bit early here and I haven't had my coffee, but I did not enjoy
> reading the discussion about this issue in the October 2009 archives of
> private@commons.  The Incubator is near or at its limits in terms of what
> sort of oversight it can provide to its projects, and adding to that burden
> simply to avoid a difficult decision doesn't make much sense to me.
> 
>>> have commons hold a public vote and make an actual decision.  If they vote to
>>> incubate the damned thing, it's an incredibly stupid decision, but so be it.
>> The end result is we want this to be a "proper" (i.e. not Sandbox)
>> Commons component - and that isn't going to happen with a completely
>> unknown (to Commons) code base & person. It needs an incubation period
>> - whether thats done through the Incubator or the Sandbox - so whats
>> the big deal?
> 
> The big deal is in how you introduce a new person into this organization.
> Either you're treating them as a colleague with things to learn, but with an
> expectation that they will succeed, or you're treating them as an outsider
> with something to prove, and an expectation that they will fail.  That is how
> I view the distinction between doing the work as an IP clearance issue that
> is managed entirely by commons, versus punting the project into the Incubator.
> 
> 
>> Niall
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 
> 
>       
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

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


Mime
View raw message