You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Donald Woods <dw...@apache.org> on 2009/12/11 02:14:12 UTC
[PROPOSAL] Validation incubator for JSR-303 Bean Validation
Hello everyone,
I would like to present an incubator proposal for a new Validation
podling, which would be a JSR-303 Bean Validation follow-on to the
existing Apache Commons Validation 1.x project, but based on a new
incoming codebase with a software grant from Agimatec GmbH.
The proposal is available on the wiki at:
http://wiki.apache.org/incubator/ValidationProposal
We're looking forward to your feedback and interest in anyone wanting to
join and help out on the project.
Thanks,
Donald
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Simone Tripodi <st...@asemantics.com>.
Hi Donald,
just to support you in the proposal and renew my interest on that project,
I've already been added in the possible contributors lists - I already
signed and sent the Apache ICLA.
Have a nice day, best regards,
Simone
On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods <dw...@apache.org> wrote:
> Hello everyone,
>
> I would like to present an incubator proposal for a new Validation podling,
> which would be a JSR-303 Bean Validation follow-on to the existing Apache
> Commons Validation 1.x project, but based on a new incoming codebase with a
> software grant from Agimatec GmbH.
>
> The proposal is available on the wiki at:
>
> http://wiki.apache.org/incubator/ValidationProposal
>
>
> We're looking forward to your feedback and interest in anyone wanting to
> join and help out on the project.
>
>
> Thanks,
> Donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
---
Simone Tripodi
Head of Application Development
Asemantics Srl
Circonvallazione Trionfale 27
00195 ROMA
Italy
T/F +39 0639751078
MP +39 3334513930
email: stripodi@asemantics.com
skype: piccolo_koenma
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Donald Woods <dw...@apache.org>.
No problem. I've updated the Required Resources and Sponsoring Entity
sections and will start the vote on another thread. Thanks.
-Donald
On 2/23/10 10:00 AM, Kevan Miller wrote:
>
> On Jan 19, 2010, at 11:45 AM, Donald Woods wrote:
>
>> Thanks. I'll get with Kevan to update the proposal before we finally
>> submit it for a vote.
>
> Oops. Donald, we never synced up. My fault. Let's get this moving along.
>
> IMO, we should structure the project as a normal incubator project, use incubator mailing list, etc. And let the Incubator process determine where the Validation project ends up in Apache. I certainly hope that is Commons.
>
> --kevan
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 19, 2010, at 11:45 AM, Donald Woods wrote:
> Thanks. I'll get with Kevan to update the proposal before we finally
> submit it for a vote.
Oops. Donald, we never synced up. My fault. Let's get this moving along.
IMO, we should structure the project as a normal incubator project, use incubator mailing list, etc. And let the Incubator process determine where the Validation project ends up in Apache. I certainly hope that is Commons.
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Donald Woods <dw...@apache.org>.
Thanks. I'll get with Kevan to update the proposal before we finally
submit it for a vote.
-Donald
On 1/18/10 9:55 PM, Noel J. Bergman wrote:
> Kevan Miller wrote:
>
>> I think we'd agree that a fair amount of community building will be
>> required for this new codebase and group of committers. [However,]
>> given the small makeup of the Commons Validator community, I don't
>> think it's reasonable to expect the Commons community to do this
>> community building.
>
> That seems a cogent enough explanation to warrant Incubation. Thank you. I
> also believe that when you talk about multiple projects collaborating
> actively on a shared, but separately useable, codebase, a TLP is often
> justified.
>
> As an aside, any issues that might relate to the Commons TLP, itself, are
> outside the scope of the Incubator, and should be addressed elswhere.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> 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
RE: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by "Noel J. Bergman" <no...@devtech.com>.
Kevan Miller wrote:
> I think we'd agree that a fair amount of community building will be
> required for this new codebase and group of committers. [However,]
> given the small makeup of the Commons Validator community, I don't
> think it's reasonable to expect the Commons community to do this
> community building.
That seems a cogent enough explanation to warrant Incubation. Thank you. I
also believe that when you talk about multiple projects collaborating
actively on a shared, but separately useable, codebase, a TLP is often
justified.
As an aside, any issues that might relate to the Commons TLP, itself, are
outside the scope of the Incubator, and should be addressed elswhere.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 18, 2010, at 11:30 AM, Noel J. Bergman wrote:
> Kevan,
>
>> Time to restart/finish this discussion.
>
> I agree. Seems that things have cooled off a bit.
>
>> Personally, I'd have been happy to see this move forward either way
>
>> 1) IP clearance with implementation work in Commons
>
> This works only if we're dealing with a CODEBASE and an existing ASF
> community that takes over it, albeit with the addition of a small number of
> new members who are part of, but not the entire, developer base for the
> code.
>
>> 2) Incubator project with graduation to Commons (or other TLP).
>
> This is the correct path if we need to incubate a community.
>
> Again, to summarize: we CLEAR code, we INCUBATE communities.
>
>> We seem to have talked our way into doing nothing.
>
> Option 3 is probably not the correct choice. :-)
:)
There's a sliding scale between those 2 options. And people may have their own evaluation of where this instance falls. Summarizing the issues:
There's an existing Commons Validator component. However, it's been mostly dormant. Commons provides the necessary oversight of the project, but there is small community of Commons committers working on the Validator component. AFAICT, there is not enough interest in the Commons community to implement the latest Bean Validation specification, on their own.
There's a partial (85%) implementation of the new JSR 303 Bean Validation Specification that Agimatec would like to donate to the ASF.
Using the initial committers list as a guide to the "community" that would be formed around this codebase: there is one Commons PMC member/committer, 6 ASF committers (but not Commons committers), and 2 non-ASF committers.
I think we'd agree that a fair amount of community building will be required for this new codebase and group of committers. A motivated TLP might be able to provide the necessary oversight to build this new community. However, given the small makeup of the Commons Validator community, I don't think it's reasonable to expect the Commons community to do this community building.
IMO, Incubator should support the creation of a new Validation project at incubator and let's start the community building...
>
>> The Geronimo project is going to need a Bean Validation implementation for
> EE6
>> compliance. So, I'm confident that there is enough interest to create an
>> implementation at Apache. I'd prefer that it end up in Commons (since this
>> is really an SE technology). However, I can start discussions in the
> Geronimo
>> community, if that's what it takes.
>
> That would be great, but given the criteria above, which direction do you
> feel that this promotes?
It only provides an alternative TLP which might have the necessary interest in building a community around this new codebase. If we are stuck in a stand-off between Commons and Incubator, this might be an alternative. However, I certainly hope it doesn't come to this...
--kevan
RE: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by "Noel J. Bergman" <no...@devtech.com>.
Kevan,
> Time to restart/finish this discussion.
I agree. Seems that things have cooled off a bit.
> Personally, I'd have been happy to see this move forward either way
> 1) IP clearance with implementation work in Commons
This works only if we're dealing with a CODEBASE and an existing ASF
community that takes over it, albeit with the addition of a small number of
new members who are part of, but not the entire, developer base for the
code.
> 2) Incubator project with graduation to Commons (or other TLP).
This is the correct path if we need to incubate a community.
Again, to summarize: we CLEAR code, we INCUBATE communities.
> We seem to have talked our way into doing nothing.
Option 3 is probably not the correct choice. :-)
> The Geronimo project is going to need a Bean Validation implementation for
EE6
> compliance. So, I'm confident that there is enough interest to create an
> implementation at Apache. I'd prefer that it end up in Commons (since this
> is really an SE technology). However, I can start discussions in the
Geronimo
> community, if that's what it takes.
That would be great, but given the criteria above, which direction do you
feel that this promotes?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 30, 2009, at 4:55 PM, Niall Pemberton wrote:
>
> This is not quite the scenario. We have a *dormant* component
> (validator) in Commons and a couple of ASF committers (not commons
> committers) have shown up proposing to re-write that component to
> implement the new "Bean Valiadation" specification. Recently one of
> those committers proposed adopting this existing code-base written by
> someone else which is already 80% complete. I was the last active
> committer on the Commons Validator component and all I'm trying to do
> is facilitate those that want to revive it and bring in the new code
> base. So its more a case of other people think Commons would be an
> appropriate home - so far none of the existing Commons committers has
> shown any interest in the codebase. Personally my interest in helping
> make this happen though is now dying 'coz this is way too painful.
Time to restart/finish this discussion.
Personally, I'd have been happy to see this move forward either way -- 1) IP clearance with implementation work in Commons or 2) Incubator project with graduation to Commons (or other TLP). We seem to have talked our way into doing nothing.
The Geronimo project is going to need a Bean Validation implementation for EE6 compliance. So, I'm confident that there is enough interest to create an implementation at Apache. I'd prefer that it end up in Commons (since this is really an SE technology). However, I can start discussions in the Geronimo community, if that's what it takes.
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by ant elder <an...@gmail.com>.
On Wed, Dec 30, 2009 at 9:55 PM, Niall Pemberton
<ni...@gmail.com> wrote:
>
> This is not quite the scenario. We have a *dormant* component
> (validator) in Commons and a couple of ASF committers (not commons
> committers) have shown up proposing to re-write that component to
> implement the new "Bean Valiadation" specification. Recently one of
> those committers proposed adopting this existing code-base written by
> someone else which is already 80% complete. I was the last active
> committer on the Commons Validator component and all I'm trying to do
> is facilitate those that want to revive it and bring in the new code
> base. So its more a case of other people think Commons would be an
> appropriate home - so far none of the existing Commons committers has
> shown any interest in the codebase. Personally my interest in helping
> make this happen though is now dying 'coz this is way too painful.
>
It doesn't have to be painful. This thread has been running a few
weeks now if it really is wanted to be done in the Incubator just call
a vote on that now. The champion and mentors are Incubator PMC members
so it'll likely get enough +1s (though the vote might go more smoothly
if the part about using the commons mailing lists is removed). The
Commons PMC is effectively saying we don't want to take responsibility
and giving it to the Incubator PMC who from the comments on this
thread will likely think its ready to graduate almost immediately so
can vote to graduate it at the earliest opportunity and give it right
back to Commons. Making work for ourselves but so be it. It doesnt
look like theres been any comments about this on commons dev or
private since the proposal was submitted to the Incubator so it may be
worth first asking there again if they'd review this thread and
reconsider not doing it via the software grant route.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Dec 30, 2009 at 7:00 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: Phil Steitz <ph...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, December 30, 2009 1:30:13 PM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> 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:
>> > 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.
>> >
>>
>> Hey Joe, the language could be toned down a bit, but I see your
>> point. On the other hand, here is the problem as I see it.
>>
>> In Commons, like other non-Incubator projects, we welcome new
>> contributors and encourage them to get involved in the community and
>> stick around long enough to earn ASF commit. When people show up
>> with significant patches, we ask them to file CLAs before we commit
>> their code and if the contribution is "big" (not precisely defined,
>> but we have been able to agree in all cases), we ask for a software
>> grant and go through Incubator IP clearance. We have several
>> examples of people showing up with large amounts of code, engaging
>> in the community and contributing patches to their own and other
>> code and earning commit that way. This has worked for us in the
>> past and is consistent with how things are supposed to work - at
>> least as I understand it - at the ASF, outside of the Incubator. If
>> we have changed our (ASF) view on what it means to become a
>> committer, then maybe we are behind the times in Commons. That
>> would be somewhat ironic, since in the Jakarta days we were
>> regularly accused of having too low a bar for commit.
>>
>> What we would have no problem at all with is following the process
>> described above - just do IP clearance / code grant for the code and
>> let the non-ASF committers earn commit. This does not take forever
>> and is not as terrible as some seem to think it is. I can't recall
>> a single "failure" (someone getting discouraged and giving up) and
>> several successes over the past 6 years.
>>
>> I understand that in the Incubator people get commit immediately and
>> that makes it easier for both them and the mentors. As I understand
>> it, part of the reason we have the Incubator is so that people who
>> have no experience with the ASF and have not earned merit can both
>> gain experience and demonstrate merit in a "mentored" environment.
>> The mentoring and graduation requirements ensure that when projects
>> graduate, their committers have earned full ASF commit.
>
> I seriously doubt mentors take their role that seriously, otherwise
> we wouldn't have so many long-term residents of the Incubator.
>
>>
>> It could be that I have this wrong and just arriving with a lump of
>> code that a project wants to incorporate is enough to earn ASF
>> commit outside the Incubator nowadays. If we collectively agreed to
>> that and I missed the conversation, then I apologize for the late
>> protest. I honestly can't believe that we did agree to that; however.
>>
>> Note that this has nothing to do with expectations about who will
>> succeed, who will not - it is about meritocracy being based on
>> publicly earned merit. Good code is good and if unencumbered we can
>> commit it to our projects. Good people interested in open
>> development make good committers and these we can include in our ASF
>> committer community. It is our collective responsibility to give as
>> many people as possible the opportunity to succeed in becoming
>> committers; but they have to do more than just produce good code to
>> earn commit.
>>
>> If we want to extend the Incubator function to work within projects,
>> I am OK with that. That could be the right way to deal with
>> situations such as this - though in this particular case, I still
>> think just software grant/earn commit is best - and it could take
>> some load off of the Incubator PMC. The role of the "sponsoring PMC"
>> would then become in loco Incubator. I am open to this, but need to
>> understand better how exactly it would work.
>>
>> Phil
>
> I'm not looking to extend the Incubator even in the smallest way. To me
> the Incubator is a necessary evil, and not entirely a positive thing for
> the ASF. That it seems to be functional on some level is good enough for
> the time being- at least we're back to graduating projects again.
>
> Where I disagree with your outlook is in the relative meaning of granting
> someone commit. To me it's just giving someone the full set of tools and
> the right (conditional on peer review) to make changes to a codebase. Each
> community can and should make their own determination on what additional
> meaning they wish to impart to committership, but communities need to be
> flexible, not rigid, in how they make those determinations.
>
> In the case of a codebase being contributed to commons that the commons
> community knows they can make use of, there is no harm in giving the
> developers of that code early commit rights to a sandbox by applying a
> different standard than commons might usually apply to a typical contributor.
> If you are concerned about the possibility that things don't work out,
> although it almost never happens commit privs *can* be revoked by a project.
This is not quite the scenario. We have a *dormant* component
(validator) in Commons and a couple of ASF committers (not commons
committers) have shown up proposing to re-write that component to
implement the new "Bean Valiadation" specification. Recently one of
those committers proposed adopting this existing code-base written by
someone else which is already 80% complete. I was the last active
committer on the Commons Validator component and all I'm trying to do
is facilitate those that want to revive it and bring in the new code
base. So its more a case of other people think Commons would be an
appropriate home - so far none of the existing Commons committers has
shown any interest in the codebase. Personally my interest in helping
make this happen though is now dying 'coz this is way too painful.
Niall
> The Incubator is for training projects, not for mentoring individuals,
> and since the primary concern here is the future activities of a few
> developers I think it's best to not involve the Incubator in any oversight
> of that. The new Community Development PMC may be able to provide a framework
> for a formal mentoring relationship that commons could use in this case.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 31, 2009, at 7:20 PM, Joe Schaefer wrote:
>
> Getting back to the subject, my primary objection to what's being proposed is that
> commons should handle this as an ip clearance, not as a project incubation. If
> commons insists that the individuals in question have to submit patches to their
> own work product for a while, that is a suboptimal choice but I can respect it.
>
I disagree that it should just be about ip clearance. If the Commons PMC has a history with the committers that come with the code then they surely can judge whether those people would be good members of the community. If they don't have any track record to go on then it is unreasonable to expect them to immediately accept them. The Commons PMC doesn't even do that for Members, except to grant them commit rights to the sandbox. However, IMO it would not be unreasonable to allow the code into the sandbox and give them only commit rights to their component. However, I'm not on the Commons PMC so my opinion is just that.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ralph Goers <ra...@dslextreme.com>
> To: general@incubator.apache.org
> Sent: Thu, December 31, 2009 9:27:26 PM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>
>
> On Dec 31, 2009, at 3:40 PM, Joe Schaefer wrote:
>
> >>
> >> As I said, we do not have a hard and fast rule on length of time,
> >> but this "nebulous notion" is what makes the ASF work.
> >
> > If that were true the incubator would need to be completely reworked,
> > because the process we use here is basically a filter on those that
> > offer to participate- graduating projects select from their committer
> > rosters who they'd like to carry on as committers or add to the PMC
> > when they go top-level.
>
> And the incubator is not your typical ASF project. By design, getting the right
> to commit is fairly easy. It is necessary to aid projects get off the ground.
>
> >
> >> The point of having a version control system
> >>> in place is that we can be lax in how we dish out permissions to it
> *because*
> >>> it's easy to fix mistakes *after* they happen. The overriding goal is to
> weed
> >>> out people who consume more collective energy than they give back, not to
> >> bestow
> >>> an honorific title on those that clear the bar.
> >>
> >> No, you have it backwards. Merit is earned and with it comes
> >> influence. You don't get it instantly and then lose it. I don't
> >> think "weeding out" those who consume more than they contribute as
> >> an organizing principle would work. It is certainly not the way we
> >> have been operating up to now at the ASF.
> >
> > You have conflated the symbols of authority with true authority- merit
> > has nothing to do with one's committer status. Being a committer doesn't
> > confer instant credibility any more than being a non-committer means one
> > is clueless. If a committer doesn't know how to work productively with
> > his/her peers, his/her work won't have any recogizable merit to those people,
> > which in the end is what matters most. Just because someone has commit
> doesn't
> > mean they have any control over the direction of a project, or even their own
> > fate- that rests with the PMC.
>
> In every ASF community I have been involved in some amount of community
> participation has had to take place before being granted commit rights. No one
> wants to find out that a person can't work productively with his/her peers after
> they have been granted commit rights. This varies from community to community
> but never have I experienced commit rights being given without some vetting. The
> closest to that was Commons, which is fairly lenient for people who already have
> commit rights elsewhere or are a member. But even there some level of commitment
> has to be demonstrated. On the other hand, in these communities once granted
> commit rights are rarely taken away unless the person asks to become emeritus or
> for some fairly extreme reason - which in my experience has been rare.
>
> Some projects delay granting commit rights because they also make the person a
> PMC member at the same time. In others, commit rights are handed out a little
> more freely but PMC membership takes quite a bit more time. Each project is free
> to handle it in the way they feel is best for their community.
>
> In all these communities anyone who has commit access has more influence then
> someone who doesn't, if for no other reason than they can take a patch from a
> Jira issue and commit it while everyone else can't. In most projects even though
> a committers vote won't officially count their vote on an issue still carries
> more weight than someone without that right.
>
> So to claim that being granted commit rights doesn't have anything to do with
> one's "authority" is incorrect.
It is the PMC that controls all aspects of the project, including whatever rights
it wishes to confer to committers. Those rights can be distributed one individual
at a time or as a class. A committer's opinion may be considered ahead of other
people's opionions, but it based on their individual merit, not their accrued status.
And in the end it may be completely discarded by the PMC if it so chooses.
Look at the Subversion project as an example of a community with a large committer
base and a full set of rules for how committers are given the right to work on various
aspects of their svn tree. (A "full committer" in Subversion maps to a PMC member
at Apache.) The rules are entirely social in nature, not enforced with authz rules.
Getting back to the subject, my primary objection to what's being proposed is that
commons should handle this as an ip clearance, not as a project incubation. If
commons insists that the individuals in question have to submit patches to their
own work product for a while, that is a suboptimal choice but I can respect it.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 31, 2009, at 3:40 PM, Joe Schaefer wrote:
>>
>> As I said, we do not have a hard and fast rule on length of time,
>> but this "nebulous notion" is what makes the ASF work.
>
> If that were true the incubator would need to be completely reworked,
> because the process we use here is basically a filter on those that
> offer to participate- graduating projects select from their committer
> rosters who they'd like to carry on as committers or add to the PMC
> when they go top-level.
And the incubator is not your typical ASF project. By design, getting the right to commit is fairly easy. It is necessary to aid projects get off the ground.
>
>> The point of having a version control system
>>> in place is that we can be lax in how we dish out permissions to it *because*
>>> it's easy to fix mistakes *after* they happen. The overriding goal is to weed
>>> out people who consume more collective energy than they give back, not to
>> bestow
>>> an honorific title on those that clear the bar.
>>
>> No, you have it backwards. Merit is earned and with it comes
>> influence. You don't get it instantly and then lose it. I don't
>> think "weeding out" those who consume more than they contribute as
>> an organizing principle would work. It is certainly not the way we
>> have been operating up to now at the ASF.
>
> You have conflated the symbols of authority with true authority- merit
> has nothing to do with one's committer status. Being a committer doesn't
> confer instant credibility any more than being a non-committer means one
> is clueless. If a committer doesn't know how to work productively with
> his/her peers, his/her work won't have any recogizable merit to those people,
> which in the end is what matters most. Just because someone has commit doesn't
> mean they have any control over the direction of a project, or even their own
> fate- that rests with the PMC.
In every ASF community I have been involved in some amount of community participation has had to take place before being granted commit rights. No one wants to find out that a person can't work productively with his/her peers after they have been granted commit rights. This varies from community to community but never have I experienced commit rights being given without some vetting. The closest to that was Commons, which is fairly lenient for people who already have commit rights elsewhere or are a member. But even there some level of commitment has to be demonstrated. On the other hand, in these communities once granted commit rights are rarely taken away unless the person asks to become emeritus or for some fairly extreme reason - which in my experience has been rare.
Some projects delay granting commit rights because they also make the person a PMC member at the same time. In others, commit rights are handed out a little more freely but PMC membership takes quite a bit more time. Each project is free to handle it in the way they feel is best for their community.
In all these communities anyone who has commit access has more influence then someone who doesn't, if for no other reason than they can take a patch from a Jira issue and commit it while everyone else can't. In most projects even though a committers vote won't officially count their vote on an issue still carries more weight than someone without that right.
So to claim that being granted commit rights doesn't have anything to do with one's "authority" is incorrect.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Phil Steitz <ph...@gmail.com>
> To: general@incubator.apache.org
> Sent: Thu, December 31, 2009 1:54:18 AM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>
> Joe Schaefer wrote:
> > ----- Original Message ----
> >
> >> From: Phil Steitz
> >> To: general@incubator.apache.org
> >> Sent: Wed, December 30, 2009 3:10:47 PM
> >> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> >>
> >> Joe Schaefer wrote:
> >>> ----- Original Message ----
> >>>
> >>>> From: Phil Steitz
> >>>> To: general@incubator.apache.org
> >>>> Sent: Wed, December 30, 2009 1:30:13 PM
> >>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> >>>>
> >>>> 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:
> >>>>> 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.
> >>>>>
> >>>> Hey Joe, the language could be toned down a bit, but I see your
> >>>> point. On the other hand, here is the problem as I see it.
> >>>>
> >>>> In Commons, like other non-Incubator projects, we welcome new
> >>>> contributors and encourage them to get involved in the community and
> >>>> stick around long enough to earn ASF commit. When people show up
> >>>> with significant patches, we ask them to file CLAs before we commit
> >>>> their code and if the contribution is "big" (not precisely defined,
> >>>> but we have been able to agree in all cases), we ask for a software
> >>>> grant and go through Incubator IP clearance. We have several
> >>>> examples of people showing up with large amounts of code, engaging
> >>>> in the community and contributing patches to their own and other
> >>>> code and earning commit that way. This has worked for us in the
> >>>> past and is consistent with how things are supposed to work - at
> >>>> least as I understand it - at the ASF, outside of the Incubator. If
> >>>> we have changed our (ASF) view on what it means to become a
> >>>> committer, then maybe we are behind the times in Commons. That
> >>>> would be somewhat ironic, since in the Jakarta days we were
> >>>> regularly accused of having too low a bar for commit.
> >>>>
> >>>> What we would have no problem at all with is following the process
> >>>> described above - just do IP clearance / code grant for the code and
> >>>> let the non-ASF committers earn commit. This does not take forever
> >>>> and is not as terrible as some seem to think it is. I can't recall
> >>>> a single "failure" (someone getting discouraged and giving up) and
> >>>> several successes over the past 6 years.
> >>>>
> >>>> I understand that in the Incubator people get commit immediately and
> >>>> that makes it easier for both them and the mentors. As I understand
> >>>> it, part of the reason we have the Incubator is so that people who
> >>>> have no experience with the ASF and have not earned merit can both
> >>>> gain experience and demonstrate merit in a "mentored" environment.
> >>>> The mentoring and graduation requirements ensure that when projects
> >>>> graduate, their committers have earned full ASF commit.
> >>> I seriously doubt mentors take their role that seriously, otherwise
> >>> we wouldn't have so many long-term residents of the Incubator.
> >>>
> >>>> It could be that I have this wrong and just arriving with a lump of
> >>>> code that a project wants to incorporate is enough to earn ASF
> >>>> commit outside the Incubator nowadays. If we collectively agreed to
> >>>> that and I missed the conversation, then I apologize for the late
> >>>> protest. I honestly can't believe that we did agree to that; however.
> >>>>
> >>>> Note that this has nothing to do with expectations about who will
> >>>> succeed, who will not - it is about meritocracy being based on
> >>>> publicly earned merit. Good code is good and if unencumbered we can
> >>>> commit it to our projects. Good people interested in open
> >>>> development make good committers and these we can include in our ASF
> >>>> committer community. It is our collective responsibility to give as
> >>>> many people as possible the opportunity to succeed in becoming
> >>>> committers; but they have to do more than just produce good code to
> >>>> earn commit.
> >>>>
> >>>> If we want to extend the Incubator function to work within projects,
> >>>> I am OK with that. That could be the right way to deal with
> >>>> situations such as this - though in this particular case, I still
> >>>> think just software grant/earn commit is best - and it could take
> >>>> some load off of the Incubator PMC. The role of the "sponsoring PMC"
> >>>> would then become in loco Incubator. I am open to this, but need to
> >>>> understand better how exactly it would work.
> >>>>
> >>>> Phil
> >>> I'm not looking to extend the Incubator even in the smallest way. To me
> >>> the Incubator is a necessary evil, and not entirely a positive thing for
> >>> the ASF. That it seems to be functional on some level is good enough for
> >>> the time being- at least we're back to graduating projects again.
> >>>
> >>> Where I disagree with your outlook is in the relative meaning of granting
> >>> someone commit. To me it's just giving someone the full set of tools and
> >>> the right (conditional on peer review) to make changes to a codebase. Each
> >>> community can and should make their own determination on what additional
> >>> meaning they wish to impart to committership, but communities need to be
> >>> flexible, not rigid, in how they make those determinations.
> >> So should commit require merit or not? I understand the need for
> >> flexibility, but if we are going to have a meaningful "committer"
> >> role, we need to be consistent (at least within projects) what it
> >> means. At commons, we are not rigid, but we do require sustained
> >> contributions (vaguely defined, but at least a few months) before we
> >> vote someone in as a committer. This is because being voted in
> >> means something in terms of merit. We could change that and divorce
> >> commit from merit - postponing the merit requirement until the PMC
> >> membership vote. Is this what you mean?
> >
> > I don't see any need for several months to pass before being able to figure
> > out if someone is participating to further the group's goals and understands
> > the group's unique style of work. That is the distinguishing characteristic
> > of whether someone should be given full access to subversion IMO, not some
> > nebulous notion of accrued merit.
>
> As I said, we do not have a hard and fast rule on length of time,
> but this "nebulous notion" is what makes the ASF work.
If that were true the incubator would need to be completely reworked,
because the process we use here is basically a filter on those that
offer to participate- graduating projects select from their committer
rosters who they'd like to carry on as committers or add to the PMC
when they go top-level.
> The point of having a version control system
> > in place is that we can be lax in how we dish out permissions to it *because*
> > it's easy to fix mistakes *after* they happen. The overriding goal is to weed
> > out people who consume more collective energy than they give back, not to
> bestow
> > an honorific title on those that clear the bar.
>
> No, you have it backwards. Merit is earned and with it comes
> influence. You don't get it instantly and then lose it. I don't
> think "weeding out" those who consume more than they contribute as
> an organizing principle would work. It is certainly not the way we
> have been operating up to now at the ASF.
You have conflated the symbols of authority with true authority- merit
has nothing to do with one's committer status. Being a committer doesn't
confer instant credibility any more than being a non-committer means one
is clueless. If a committer doesn't know how to work productively with
his/her peers, his/her work won't have any recogizable merit to those people,
which in the end is what matters most. Just because someone has commit doesn't
mean they have any control over the direction of a project, or even their own
fate- that rests with the PMC.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Dec 31, 2009 at 2:54 PM, Phil Steitz <ph...@gmail.com> wrote:
> I don't
> think "weeding out" those who consume more than they contribute as
> an organizing principle would work. It is certainly not the way we
> have been operating up to now at the ASF.
Yes it is. "consuming" in this context is more like "creating more
problem for the community". The few cases (that I know of) where merit
was revoked or threatened to be revoked, was due to consumption of
community energy beyond the contribution given.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Phil Steitz <ph...@gmail.com>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Phil Steitz <ph...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, December 30, 2009 3:10:47 PM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> Joe Schaefer wrote:
>>> ----- Original Message ----
>>>
>>>> From: Phil Steitz
>>>> To: general@incubator.apache.org
>>>> Sent: Wed, December 30, 2009 1:30:13 PM
>>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>>>
>>>> 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:
>>>>> 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.
>>>>>
>>>> Hey Joe, the language could be toned down a bit, but I see your
>>>> point. On the other hand, here is the problem as I see it.
>>>>
>>>> In Commons, like other non-Incubator projects, we welcome new
>>>> contributors and encourage them to get involved in the community and
>>>> stick around long enough to earn ASF commit. When people show up
>>>> with significant patches, we ask them to file CLAs before we commit
>>>> their code and if the contribution is "big" (not precisely defined,
>>>> but we have been able to agree in all cases), we ask for a software
>>>> grant and go through Incubator IP clearance. We have several
>>>> examples of people showing up with large amounts of code, engaging
>>>> in the community and contributing patches to their own and other
>>>> code and earning commit that way. This has worked for us in the
>>>> past and is consistent with how things are supposed to work - at
>>>> least as I understand it - at the ASF, outside of the Incubator. If
>>>> we have changed our (ASF) view on what it means to become a
>>>> committer, then maybe we are behind the times in Commons. That
>>>> would be somewhat ironic, since in the Jakarta days we were
>>>> regularly accused of having too low a bar for commit.
>>>>
>>>> What we would have no problem at all with is following the process
>>>> described above - just do IP clearance / code grant for the code and
>>>> let the non-ASF committers earn commit. This does not take forever
>>>> and is not as terrible as some seem to think it is. I can't recall
>>>> a single "failure" (someone getting discouraged and giving up) and
>>>> several successes over the past 6 years.
>>>>
>>>> I understand that in the Incubator people get commit immediately and
>>>> that makes it easier for both them and the mentors. As I understand
>>>> it, part of the reason we have the Incubator is so that people who
>>>> have no experience with the ASF and have not earned merit can both
>>>> gain experience and demonstrate merit in a "mentored" environment.
>>>> The mentoring and graduation requirements ensure that when projects
>>>> graduate, their committers have earned full ASF commit.
>>> I seriously doubt mentors take their role that seriously, otherwise
>>> we wouldn't have so many long-term residents of the Incubator.
>>>
>>>> It could be that I have this wrong and just arriving with a lump of
>>>> code that a project wants to incorporate is enough to earn ASF
>>>> commit outside the Incubator nowadays. If we collectively agreed to
>>>> that and I missed the conversation, then I apologize for the late
>>>> protest. I honestly can't believe that we did agree to that; however.
>>>>
>>>> Note that this has nothing to do with expectations about who will
>>>> succeed, who will not - it is about meritocracy being based on
>>>> publicly earned merit. Good code is good and if unencumbered we can
>>>> commit it to our projects. Good people interested in open
>>>> development make good committers and these we can include in our ASF
>>>> committer community. It is our collective responsibility to give as
>>>> many people as possible the opportunity to succeed in becoming
>>>> committers; but they have to do more than just produce good code to
>>>> earn commit.
>>>>
>>>> If we want to extend the Incubator function to work within projects,
>>>> I am OK with that. That could be the right way to deal with
>>>> situations such as this - though in this particular case, I still
>>>> think just software grant/earn commit is best - and it could take
>>>> some load off of the Incubator PMC. The role of the "sponsoring PMC"
>>>> would then become in loco Incubator. I am open to this, but need to
>>>> understand better how exactly it would work.
>>>>
>>>> Phil
>>> I'm not looking to extend the Incubator even in the smallest way. To me
>>> the Incubator is a necessary evil, and not entirely a positive thing for
>>> the ASF. That it seems to be functional on some level is good enough for
>>> the time being- at least we're back to graduating projects again.
>>>
>>> Where I disagree with your outlook is in the relative meaning of granting
>>> someone commit. To me it's just giving someone the full set of tools and
>>> the right (conditional on peer review) to make changes to a codebase. Each
>>> community can and should make their own determination on what additional
>>> meaning they wish to impart to committership, but communities need to be
>>> flexible, not rigid, in how they make those determinations.
>> So should commit require merit or not? I understand the need for
>> flexibility, but if we are going to have a meaningful "committer"
>> role, we need to be consistent (at least within projects) what it
>> means. At commons, we are not rigid, but we do require sustained
>> contributions (vaguely defined, but at least a few months) before we
>> vote someone in as a committer. This is because being voted in
>> means something in terms of merit. We could change that and divorce
>> commit from merit - postponing the merit requirement until the PMC
>> membership vote. Is this what you mean?
>
> I don't see any need for several months to pass before being able to figure
> out if someone is participating to further the group's goals and understands
> the group's unique style of work. That is the distinguishing characteristic
> of whether someone should be given full access to subversion IMO, not some
> nebulous notion of accrued merit.
As I said, we do not have a hard and fast rule on length of time,
but this "nebulous notion" is what makes the ASF work.
The point of having a version control system
> in place is that we can be lax in how we dish out permissions to it *because*
> it's easy to fix mistakes *after* they happen. The overriding goal is to weed
> out people who consume more collective energy than they give back, not to bestow
> an honorific title on those that clear the bar.
No, you have it backwards. Merit is earned and with it comes
influence. You don't get it instantly and then lose it. I don't
think "weeding out" those who consume more than they contribute as
an organizing principle would work. It is certainly not the way we
have been operating up to now at the ASF.
Phil
>
> The reason we give out commit access is so people can be full participants in
> collaborative work at the ASF. There are additional benefits when it comes to
> conference fees, but that's the gist of it. Everything else is artificial.
>
> As Niall points out, there seems to be some open question as to how much interest
> there is within the commons community to provide support for this effort. That's
> not made any easier by moving things into the Incubator IMO. Personally if I were
> Niall and were still willing to mentor these people, it would make my life easier
> if they had commit to the sandbox so I could comment on their full range of work
> habits. If you wanted to you could lock down their commit access to just the sandbox.
> OTOH it'd be a big PITA to proxy their commits by having them submit patches for
> me to process. In other words, be lazy and optimize for the mentor's time, because
> that is the scarce resource here.
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Phil Steitz <ph...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, December 30, 2009 3:10:47 PM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>
> Joe Schaefer wrote:
> > ----- Original Message ----
> >
> >> From: Phil Steitz
> >> To: general@incubator.apache.org
> >> Sent: Wed, December 30, 2009 1:30:13 PM
> >> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> >>
> >> 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:
> >>> 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.
> >>>
> >> Hey Joe, the language could be toned down a bit, but I see your
> >> point. On the other hand, here is the problem as I see it.
> >>
> >> In Commons, like other non-Incubator projects, we welcome new
> >> contributors and encourage them to get involved in the community and
> >> stick around long enough to earn ASF commit. When people show up
> >> with significant patches, we ask them to file CLAs before we commit
> >> their code and if the contribution is "big" (not precisely defined,
> >> but we have been able to agree in all cases), we ask for a software
> >> grant and go through Incubator IP clearance. We have several
> >> examples of people showing up with large amounts of code, engaging
> >> in the community and contributing patches to their own and other
> >> code and earning commit that way. This has worked for us in the
> >> past and is consistent with how things are supposed to work - at
> >> least as I understand it - at the ASF, outside of the Incubator. If
> >> we have changed our (ASF) view on what it means to become a
> >> committer, then maybe we are behind the times in Commons. That
> >> would be somewhat ironic, since in the Jakarta days we were
> >> regularly accused of having too low a bar for commit.
> >>
> >> What we would have no problem at all with is following the process
> >> described above - just do IP clearance / code grant for the code and
> >> let the non-ASF committers earn commit. This does not take forever
> >> and is not as terrible as some seem to think it is. I can't recall
> >> a single "failure" (someone getting discouraged and giving up) and
> >> several successes over the past 6 years.
> >>
> >> I understand that in the Incubator people get commit immediately and
> >> that makes it easier for both them and the mentors. As I understand
> >> it, part of the reason we have the Incubator is so that people who
> >> have no experience with the ASF and have not earned merit can both
> >> gain experience and demonstrate merit in a "mentored" environment.
> >> The mentoring and graduation requirements ensure that when projects
> >> graduate, their committers have earned full ASF commit.
> >
> > I seriously doubt mentors take their role that seriously, otherwise
> > we wouldn't have so many long-term residents of the Incubator.
> >
> >> It could be that I have this wrong and just arriving with a lump of
> >> code that a project wants to incorporate is enough to earn ASF
> >> commit outside the Incubator nowadays. If we collectively agreed to
> >> that and I missed the conversation, then I apologize for the late
> >> protest. I honestly can't believe that we did agree to that; however.
> >>
> >> Note that this has nothing to do with expectations about who will
> >> succeed, who will not - it is about meritocracy being based on
> >> publicly earned merit. Good code is good and if unencumbered we can
> >> commit it to our projects. Good people interested in open
> >> development make good committers and these we can include in our ASF
> >> committer community. It is our collective responsibility to give as
> >> many people as possible the opportunity to succeed in becoming
> >> committers; but they have to do more than just produce good code to
> >> earn commit.
> >>
> >> If we want to extend the Incubator function to work within projects,
> >> I am OK with that. That could be the right way to deal with
> >> situations such as this - though in this particular case, I still
> >> think just software grant/earn commit is best - and it could take
> >> some load off of the Incubator PMC. The role of the "sponsoring PMC"
> >> would then become in loco Incubator. I am open to this, but need to
> >> understand better how exactly it would work.
> >>
> >> Phil
> >
> > I'm not looking to extend the Incubator even in the smallest way. To me
> > the Incubator is a necessary evil, and not entirely a positive thing for
> > the ASF. That it seems to be functional on some level is good enough for
> > the time being- at least we're back to graduating projects again.
> >
> > Where I disagree with your outlook is in the relative meaning of granting
> > someone commit. To me it's just giving someone the full set of tools and
> > the right (conditional on peer review) to make changes to a codebase. Each
> > community can and should make their own determination on what additional
> > meaning they wish to impart to committership, but communities need to be
> > flexible, not rigid, in how they make those determinations.
>
> So should commit require merit or not? I understand the need for
> flexibility, but if we are going to have a meaningful "committer"
> role, we need to be consistent (at least within projects) what it
> means. At commons, we are not rigid, but we do require sustained
> contributions (vaguely defined, but at least a few months) before we
> vote someone in as a committer. This is because being voted in
> means something in terms of merit. We could change that and divorce
> commit from merit - postponing the merit requirement until the PMC
> membership vote. Is this what you mean?
I don't see any need for several months to pass before being able to figure
out if someone is participating to further the group's goals and understands
the group's unique style of work. That is the distinguishing characteristic
of whether someone should be given full access to subversion IMO, not some
nebulous notion of accrued merit. The point of having a version control system
in place is that we can be lax in how we dish out permissions to it *because*
it's easy to fix mistakes *after* they happen. The overriding goal is to weed
out people who consume more collective energy than they give back, not to bestow
an honorific title on those that clear the bar.
The reason we give out commit access is so people can be full participants in
collaborative work at the ASF. There are additional benefits when it comes to
conference fees, but that's the gist of it. Everything else is artificial.
As Niall points out, there seems to be some open question as to how much interest
there is within the commons community to provide support for this effort. That's
not made any easier by moving things into the Incubator IMO. Personally if I were
Niall and were still willing to mentor these people, it would make my life easier
if they had commit to the sandbox so I could comment on their full range of work
habits. If you wanted to you could lock down their commit access to just the sandbox.
OTOH it'd be a big PITA to proxy their commits by having them submit patches for
me to process. In other words, be lazy and optimize for the mentor's time, because
that is the scarce resource here.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Phil Steitz <ph...@gmail.com>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Phil Steitz <ph...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, December 30, 2009 1:30:13 PM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> 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:
>>> 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.
>>>
>> Hey Joe, the language could be toned down a bit, but I see your
>> point. On the other hand, here is the problem as I see it.
>>
>> In Commons, like other non-Incubator projects, we welcome new
>> contributors and encourage them to get involved in the community and
>> stick around long enough to earn ASF commit. When people show up
>> with significant patches, we ask them to file CLAs before we commit
>> their code and if the contribution is "big" (not precisely defined,
>> but we have been able to agree in all cases), we ask for a software
>> grant and go through Incubator IP clearance. We have several
>> examples of people showing up with large amounts of code, engaging
>> in the community and contributing patches to their own and other
>> code and earning commit that way. This has worked for us in the
>> past and is consistent with how things are supposed to work - at
>> least as I understand it - at the ASF, outside of the Incubator. If
>> we have changed our (ASF) view on what it means to become a
>> committer, then maybe we are behind the times in Commons. That
>> would be somewhat ironic, since in the Jakarta days we were
>> regularly accused of having too low a bar for commit.
>>
>> What we would have no problem at all with is following the process
>> described above - just do IP clearance / code grant for the code and
>> let the non-ASF committers earn commit. This does not take forever
>> and is not as terrible as some seem to think it is. I can't recall
>> a single "failure" (someone getting discouraged and giving up) and
>> several successes over the past 6 years.
>>
>> I understand that in the Incubator people get commit immediately and
>> that makes it easier for both them and the mentors. As I understand
>> it, part of the reason we have the Incubator is so that people who
>> have no experience with the ASF and have not earned merit can both
>> gain experience and demonstrate merit in a "mentored" environment.
>> The mentoring and graduation requirements ensure that when projects
>> graduate, their committers have earned full ASF commit.
>
> I seriously doubt mentors take their role that seriously, otherwise
> we wouldn't have so many long-term residents of the Incubator.
>
>> It could be that I have this wrong and just arriving with a lump of
>> code that a project wants to incorporate is enough to earn ASF
>> commit outside the Incubator nowadays. If we collectively agreed to
>> that and I missed the conversation, then I apologize for the late
>> protest. I honestly can't believe that we did agree to that; however.
>>
>> Note that this has nothing to do with expectations about who will
>> succeed, who will not - it is about meritocracy being based on
>> publicly earned merit. Good code is good and if unencumbered we can
>> commit it to our projects. Good people interested in open
>> development make good committers and these we can include in our ASF
>> committer community. It is our collective responsibility to give as
>> many people as possible the opportunity to succeed in becoming
>> committers; but they have to do more than just produce good code to
>> earn commit.
>>
>> If we want to extend the Incubator function to work within projects,
>> I am OK with that. That could be the right way to deal with
>> situations such as this - though in this particular case, I still
>> think just software grant/earn commit is best - and it could take
>> some load off of the Incubator PMC. The role of the "sponsoring PMC"
>> would then become in loco Incubator. I am open to this, but need to
>> understand better how exactly it would work.
>>
>> Phil
>
> I'm not looking to extend the Incubator even in the smallest way. To me
> the Incubator is a necessary evil, and not entirely a positive thing for
> the ASF. That it seems to be functional on some level is good enough for
> the time being- at least we're back to graduating projects again.
>
> Where I disagree with your outlook is in the relative meaning of granting
> someone commit. To me it's just giving someone the full set of tools and
> the right (conditional on peer review) to make changes to a codebase. Each
> community can and should make their own determination on what additional
> meaning they wish to impart to committership, but communities need to be
> flexible, not rigid, in how they make those determinations.
So should commit require merit or not? I understand the need for
flexibility, but if we are going to have a meaningful "committer"
role, we need to be consistent (at least within projects) what it
means. At commons, we are not rigid, but we do require sustained
contributions (vaguely defined, but at least a few months) before we
vote someone in as a committer. This is because being voted in
means something in terms of merit. We could change that and divorce
commit from merit - postponing the merit requirement until the PMC
membership vote. Is this what you mean?
>
> In the case of a codebase being contributed to commons that the commons
> community knows they can make use of, there is no harm in giving the
> developers of that code early commit rights to a sandbox by applying a
> different standard than commons might usually apply to a typical contributor.
> If you are concerned about the possibility that things don't work out,
> although it almost never happens commit privs *can* be revoked by a project.
>
> The Incubator is for training projects, not for mentoring individuals,
> and since the primary concern here is the future activities of a few
> developers I think it's best to not involve the Incubator in any oversight
> of that.
Sorry if it sounded like I was trying to push the responsibility for
Commons oversight to the Incubator. Not at all what I meant. I just
want to make sure that if we do start "incubating" inside commons
with no Incubator oversight, we have a minimally sufficient
structure in place to support it.
Phil
The new Community Development PMC may be able to provide a framework
> for a formal mentoring relationship that commons could use in this case.
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Phil Steitz <ph...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, December 30, 2009 1:30:13 PM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>
> 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:
> > 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.
> >
>
> Hey Joe, the language could be toned down a bit, but I see your
> point. On the other hand, here is the problem as I see it.
>
> In Commons, like other non-Incubator projects, we welcome new
> contributors and encourage them to get involved in the community and
> stick around long enough to earn ASF commit. When people show up
> with significant patches, we ask them to file CLAs before we commit
> their code and if the contribution is "big" (not precisely defined,
> but we have been able to agree in all cases), we ask for a software
> grant and go through Incubator IP clearance. We have several
> examples of people showing up with large amounts of code, engaging
> in the community and contributing patches to their own and other
> code and earning commit that way. This has worked for us in the
> past and is consistent with how things are supposed to work - at
> least as I understand it - at the ASF, outside of the Incubator. If
> we have changed our (ASF) view on what it means to become a
> committer, then maybe we are behind the times in Commons. That
> would be somewhat ironic, since in the Jakarta days we were
> regularly accused of having too low a bar for commit.
>
> What we would have no problem at all with is following the process
> described above - just do IP clearance / code grant for the code and
> let the non-ASF committers earn commit. This does not take forever
> and is not as terrible as some seem to think it is. I can't recall
> a single "failure" (someone getting discouraged and giving up) and
> several successes over the past 6 years.
>
> I understand that in the Incubator people get commit immediately and
> that makes it easier for both them and the mentors. As I understand
> it, part of the reason we have the Incubator is so that people who
> have no experience with the ASF and have not earned merit can both
> gain experience and demonstrate merit in a "mentored" environment.
> The mentoring and graduation requirements ensure that when projects
> graduate, their committers have earned full ASF commit.
I seriously doubt mentors take their role that seriously, otherwise
we wouldn't have so many long-term residents of the Incubator.
>
> It could be that I have this wrong and just arriving with a lump of
> code that a project wants to incorporate is enough to earn ASF
> commit outside the Incubator nowadays. If we collectively agreed to
> that and I missed the conversation, then I apologize for the late
> protest. I honestly can't believe that we did agree to that; however.
>
> Note that this has nothing to do with expectations about who will
> succeed, who will not - it is about meritocracy being based on
> publicly earned merit. Good code is good and if unencumbered we can
> commit it to our projects. Good people interested in open
> development make good committers and these we can include in our ASF
> committer community. It is our collective responsibility to give as
> many people as possible the opportunity to succeed in becoming
> committers; but they have to do more than just produce good code to
> earn commit.
>
> If we want to extend the Incubator function to work within projects,
> I am OK with that. That could be the right way to deal with
> situations such as this - though in this particular case, I still
> think just software grant/earn commit is best - and it could take
> some load off of the Incubator PMC. The role of the "sponsoring PMC"
> would then become in loco Incubator. I am open to this, but need to
> understand better how exactly it would work.
>
> Phil
I'm not looking to extend the Incubator even in the smallest way. To me
the Incubator is a necessary evil, and not entirely a positive thing for
the ASF. That it seems to be functional on some level is good enough for
the time being- at least we're back to graduating projects again.
Where I disagree with your outlook is in the relative meaning of granting
someone commit. To me it's just giving someone the full set of tools and
the right (conditional on peer review) to make changes to a codebase. Each
community can and should make their own determination on what additional
meaning they wish to impart to committership, but communities need to be
flexible, not rigid, in how they make those determinations.
In the case of a codebase being contributed to commons that the commons
community knows they can make use of, there is no harm in giving the
developers of that code early commit rights to a sandbox by applying a
different standard than commons might usually apply to a typical contributor.
If you are concerned about the possibility that things don't work out,
although it almost never happens commit privs *can* be revoked by a project.
The Incubator is for training projects, not for mentoring individuals,
and since the primary concern here is the future activities of a few
developers I think it's best to not involve the Incubator in any oversight
of that. The new Community Development PMC may be able to provide a framework
for a formal mentoring relationship that commons could use in this case.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Phil Steitz <ph...@gmail.com>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: ant elder <an...@apache.org>
>> 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:
> 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.
>
Hey Joe, the language could be toned down a bit, but I see your
point. On the other hand, here is the problem as I see it.
In Commons, like other non-Incubator projects, we welcome new
contributors and encourage them to get involved in the community and
stick around long enough to earn ASF commit. When people show up
with significant patches, we ask them to file CLAs before we commit
their code and if the contribution is "big" (not precisely defined,
but we have been able to agree in all cases), we ask for a software
grant and go through Incubator IP clearance. We have several
examples of people showing up with large amounts of code, engaging
in the community and contributing patches to their own and other
code and earning commit that way. This has worked for us in the
past and is consistent with how things are supposed to work - at
least as I understand it - at the ASF, outside of the Incubator. If
we have changed our (ASF) view on what it means to become a
committer, then maybe we are behind the times in Commons. That
would be somewhat ironic, since in the Jakarta days we were
regularly accused of having too low a bar for commit.
What we would have no problem at all with is following the process
described above - just do IP clearance / code grant for the code and
let the non-ASF committers earn commit. This does not take forever
and is not as terrible as some seem to think it is. I can't recall
a single "failure" (someone getting discouraged and giving up) and
several successes over the past 6 years.
I understand that in the Incubator people get commit immediately and
that makes it easier for both them and the mentors. As I understand
it, part of the reason we have the Incubator is so that people who
have no experience with the ASF and have not earned merit can both
gain experience and demonstrate merit in a "mentored" environment.
The mentoring and graduation requirements ensure that when projects
graduate, their committers have earned full ASF commit.
It could be that I have this wrong and just arriving with a lump of
code that a project wants to incorporate is enough to earn ASF
commit outside the Incubator nowadays. If we collectively agreed to
that and I missed the conversation, then I apologize for the late
protest. I honestly can't believe that we did agree to that; however.
Note that this has nothing to do with expectations about who will
succeed, who will not - it is about meritocracy being based on
publicly earned merit. Good code is good and if unencumbered we can
commit it to our projects. Good people interested in open
development make good committers and these we can include in our ASF
committer community. It is our collective responsibility to give as
many people as possible the opportunity to succeed in becoming
committers; but they have to do more than just produce good code to
earn commit.
If we want to extend the Incubator function to work within projects,
I am OK with that. That could be the right way to deal with
situations such as this - though in this particular case, I still
think just software grant/earn commit is best - and it could take
some load off of the Incubator PMC. The role of the "sponsoring PMC"
would then become in loco Incubator. I am open to this, but need to
understand better how exactly it would work.
Phil
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
I've said my peace on this issue. If the committer(s) need mentors to help
them learn the ropes, try working with the new dev@community.apache.org list
to set up a formal arrangement.
OTOH I won't stand in the way if commons insists on incubating this effort.
----- Original Message ----
> From: Donald Woods <dw...@apache.org>
> To: general@incubator.apache.org
> Sent: Fri, December 11, 2009 12:08:50 PM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>
> 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
> >> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Donald Woods <dw...@apache.org>.
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 <ni...@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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Niall Pemberton <ni...@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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Dec 11, 2009 at 10:42 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: ant elder <an...@apache.org>
>> 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)?
> 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?
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: ant elder <an...@apache.org>
> 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:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by ant elder <an...@apache.org>.
On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Fri, Dec 11, 2009 at 7:56 AM, ant elder <an...@gmail.com> 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
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Dec 11, 2009 at 7:56 AM, ant elder <an...@gmail.com> 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
> ...ant
>
> [1] http://apache.markmail.org/search/?q=jsr+303+list%3Aorg.apache.commons.dev#query:jsr%20303%20list%3Aorg.apache.commons.dev%20order%3Adate-backward+page:1+state:facets
>
>
> On Fri, Dec 11, 2009 at 7:06 AM, Matthias Wessendorf <ma...@apache.org> wrote:
>> Hi,
>>
>> what about the effort from the Jakarta/Commons Validator community?
>> Aren't they doing that as well ? (or was it only stated to do so)?
>>
>> -Matthias
>>
>> On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods <dw...@apache.org> wrote:
>>> Hello everyone,
>>>
>>> I would like to present an incubator proposal for a new Validation podling,
>>> which would be a JSR-303 Bean Validation follow-on to the existing Apache
>>> Commons Validation 1.x project, but based on a new incoming codebase with a
>>> software grant from Agimatec GmbH.
>>>
>>> The proposal is available on the wiki at:
>>>
>>> http://wiki.apache.org/incubator/ValidationProposal
>>>
>>>
>>> We're looking forward to your feedback and interest in anyone wanting to
>>> join and help out on the project.
>>>
>>>
>>> Thanks,
>>> Donald
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by ant elder <an...@gmail.com>.
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?
...ant
[1] http://apache.markmail.org/search/?q=jsr+303+list%3Aorg.apache.commons.dev#query:jsr%20303%20list%3Aorg.apache.commons.dev%20order%3Adate-backward+page:1+state:facets
On Fri, Dec 11, 2009 at 7:06 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi,
>
> what about the effort from the Jakarta/Commons Validator community?
> Aren't they doing that as well ? (or was it only stated to do so)?
>
> -Matthias
>
> On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods <dw...@apache.org> wrote:
>> Hello everyone,
>>
>> I would like to present an incubator proposal for a new Validation podling,
>> which would be a JSR-303 Bean Validation follow-on to the existing Apache
>> Commons Validation 1.x project, but based on a new incoming codebase with a
>> software grant from Agimatec GmbH.
>>
>> The proposal is available on the wiki at:
>>
>> http://wiki.apache.org/incubator/ValidationProposal
>>
>>
>> We're looking forward to your feedback and interest in anyone wanting to
>> join and help out on the project.
>>
>>
>> Thanks,
>> Donald
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Henri Yandell <ba...@apache.org>.
It's related. Commons are sponsoring this incubation.
Hen
On Thu, Dec 10, 2009 at 11:06 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi,
>
> what about the effort from the Jakarta/Commons Validator community?
> Aren't they doing that as well ? (or was it only stated to do so)?
>
> -Matthias
>
> On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods <dw...@apache.org> wrote:
>> Hello everyone,
>>
>> I would like to present an incubator proposal for a new Validation podling,
>> which would be a JSR-303 Bean Validation follow-on to the existing Apache
>> Commons Validation 1.x project, but based on a new incoming codebase with a
>> software grant from Agimatec GmbH.
>>
>> The proposal is available on the wiki at:
>>
>> http://wiki.apache.org/incubator/ValidationProposal
>>
>>
>> We're looking forward to your feedback and interest in anyone wanting to
>> join and help out on the project.
>>
>>
>> Thanks,
>> Donald
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
what about the effort from the Jakarta/Commons Validator community?
Aren't they doing that as well ? (or was it only stated to do so)?
-Matthias
On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods <dw...@apache.org> wrote:
> Hello everyone,
>
> I would like to present an incubator proposal for a new Validation podling,
> which would be a JSR-303 Bean Validation follow-on to the existing Apache
> Commons Validation 1.x project, but based on a new incoming codebase with a
> software grant from Agimatec GmbH.
>
> The proposal is available on the wiki at:
>
> http://wiki.apache.org/incubator/ValidationProposal
>
>
> We're looking forward to your feedback and interest in anyone wanting to
> join and help out on the project.
>
>
> Thanks,
> Donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
+1
On Fri, Dec 11, 2009 at 3:14 AM, Donald Woods <dw...@apache.org> wrote:
> Hello everyone,
>
> I would like to present an incubator proposal for a new Validation podling,
> which would be a JSR-303 Bean Validation follow-on to the existing Apache
> Commons Validation 1.x project, but based on a new incoming codebase with a
> software grant from Agimatec GmbH.
>
> The proposal is available on the wiki at:
>
> http://wiki.apache.org/incubator/ValidationProposal
>
>
> We're looking forward to your feedback and interest in anyone wanting to
> join and help out on the project.
>
>
> Thanks,
> Donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Posted by Leo Simons <ma...@leosimons.com>.
On 12/11/09 1:14 AM, Donald Woods wrote:
> I would like to present an incubator proposal for a new Validation
> podling, which would be a JSR-303 Bean Validation follow-on to the
> existing Apache Commons Validation 1.x project, but based on a new
> incoming codebase with a software grant from Agimatec GmbH.
>
> The proposal is available on the wiki at:
>
> http://wiki.apache.org/incubator/ValidationProposal
The proposal looks fine on paper, but I'll agree with some of the other
comments that it seems a bit silly to incubate this as a disjoint project.
If you have 3 capable and able mentors *and* a whole bunch of people
that are already committers, why can't they mentor your one or two new
committers while those people are constrained to their specific sandbox,
and avoid tons of bureaucracy and overhead?
I have no real idea why anyone would think that "doing incubation" looks
like it'll have a better chance of success in this case.
Put another way - what does "doing incubation" buy you, and why is it
seen as a better option?
Can you please reconsider and see if you can do this as an ip clearance
only?
If it helps I can hop on a mailing list and object to some objections? :-D
ciao...
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org