commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject Re: [beanutils] moving reflection classes out of beanutils
Date Fri, 06 Dec 2002 16:27:05 GMT
On Thu, 5 Dec 2002, robert burrell donkin wrote:

> On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
> > --- robert burrell donkin
> > <> wrote:
> <snip>
> >> rodney hasn't been a regular contributor to
> >> beanutils either in terms of
> >> code or on the mailing lists. if he couldn't even be
> >> bothered to ask
> >> before making himself a committer
> >
> > He's not required to ask, only to indicate his
> > participation.
> asking is a matter of politeness and means that his participation is less
> likely to be vetoed.
> a committer has responsibilities as well as rights. if i thought that a
> committer was just dumping code into a component and had no intention of
> maintaining that code, i wouldn't hesitate to veto.

I really offended by this comment, Robert.  The commit you refer to was
not only well within my rights *and* responsibilities, clearly following
both the spirit and letter of the asf, jakarta, and jakarta-commons
guidelines, but also well within the bounds of politeness and courtesy.
This commit was small (one class, about ~300 lines counting comments and
blanks), unobtrusive (no new dependencies, configuration, extra processing
or memory use was introduced), fully backwards compatible, and well within
the scope of the project.  The "commit then review" protocol is clearly
appropriate (and polite) in this circumstance.  If I need your explicit
approval before making a small, unobtrusive, fully backwards compatible
and in scope commit, then Guideline #15 (Each committer has karma to all
the packages) is meaningless.

Moreover, when making a commit that fails to meet any one of these
criteria, I've very consistently brought this to the attention of the
development community, before, immediately after, or both before and after
making the commit, no matter how long I've been working on or with the
project, or for that matter whether or not I've been to primary developer
working on it, as you can see in [1] and [2] and [3] and [4] and [5] and
[6] and [7] and others.

I'm not disputing your right to question (i.e., review) this commit, but
don't suggest that it was inappropriate or impolite or somehow makes me a
bad citizen.

[1] <>
[2] <>
[3] <>
[4] <>
[5] <>
[6] <>
[7] <>

> the consensus which emerged from the lengthy discussions on this issue
> supports me, though.

That's not "consensus" in the standard meaning--there are those that
disagree with this approach.  It's certainly not "consensus" in any formal
ASF sense, since there was no actual [VOTE] on the issue, so claiming it
as a matter of policy is questionable in my eyes.

> in terms of beanutils, i'm not willing to support a release with code in
> that no one is willing to support. therefore, i'd think about vetoing
> any contribution if i thought that no one was willing to offer support
> for that code and maintain it. but you're willing to do that for
> ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you
> rodney?

I'm trying real hard not to feel condescended to here Robert.  I'm
willing to fulfill my responsiblities as an Apache committer and feel
I've got a pretty strong record of doing so.

(and from a different thread)

Costin> If duplication is a concern - then just use
Costin> beanutils ( however duplication is explicitely
Costin> allowed in commons AFAIK).

Robert> i've been convinced that beanutils is
Robert> not the right place for this code.

And I'm convinced that lang isn't the right place either.  Let's split the
difference and propose commons-reflect or commons-reflection or whatever,
and end this thread.

 - R.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message