Good points, which we discussed some on the d...@commns list before
asking the Commons PMC to sponsor this as an Incubator project.
My concerns, were around brining in a new codebase that previously had
one maintainer, but not offering them committership from the beginning,
which seemed to follow the normal meritocracy guidelines that most PMCs
follow.
If everyone feels that creating a podling for this effort is an
overkill, then I'd be fine going the IP clearance route, as long as the
existing Apache committers interested in the project are added from the
start, as there doesn't seem to be a vibrant community around the
existing Commons Validation project today.
-Donald
Joe Schaefer wrote:
----- Original Message ----
From: Niall Pemberton <niall.pember...@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 priv...@commons and reported back to d...@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 d...@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
priv...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
