incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Just added API2 Java client to SVN
Date Mon, 07 Dec 2009 17:18:29 GMT
On Mon December 7 2009 11:41:17 am Ethan Jewett wrote:
> Well, those are fair points. See below:
> 
> On Mon, Dec 7, 2009 at 9:46 AM, Daniel Kulp <dkulp@apache.org> wrote:
> > On Sun December 6 2009 7:11:13 pm Ethan Jewett wrote:
> >
> > Umm.....  Why wouldn't they be committers?
> >
> > With my mentor hat on, this statement kind of concerns me.  One of the
> > goals of the project in the incubator is to broaden the appeal of the
> > product and broaden the committer base.   Statements like the above seem
> > relatively exclusive.
> 
> My take is that they wouldn't be committers because the vast majority
> of developers and users of a project will not be committers. As far as
> I can tell, Apache committer status is a pretty high bar.

The committer status bar is as high or low as a project wants it to be.   Each 
project can really vote people in as committers using whatever criteria they 
think "feels right".   Some projects use long time frames like "6 months of 
active contributions".   Other projects using things like "6 non-trivial jira 
patches".   It's really up to the project.    

For the most part, with the projects I'm involved with, there isn't a set-in-
stone benchmark.   When we "feel" a person is ready, they get voted in. (note: 
discussions on the private list ahead of time to guage community thoughts 
around the person and possibly provide ideas to help the person make the next 
step.)

 
> Let's take this client library as an example. I don't believe Daniel
> is a committer.

He isn't....   yet.....    But the questions the ESME community needs to ask 
themselves are:
What would Daniel need to do to become a committer?   
How can we help him along the path to becoming a committer?

Daniel is obviously interested in what ESME has to offer and is willing to 
spend some time working on ESME related activities.   Is there a way to 
leverage that enthusiasm to benefit ESME at Apache?


> Because of this, if the official version of the client
> is part of the Apache project, any patches he makes to the library
> will have to go through a committer.  This is an extremely unproductive
> development strategy for the main author of a program :-) 

For now, yes.... But if  he annoys a committer with enough patches, vote him 
in.    :-)       Seriously, when someone asks "how do I become a committer on 
project XXXXX at Apache?"  the BEST answer is "annoy them with patches."

As a quick example, in CXF, we had a person that was submitting a patch nearly 
every other day for a while that ONLY corrected spelling/grammar mistakes in 
the Messages.properties file.    We voted him in to stop bothering us.  :-)   
He then contributed in other ways as well and has worked out very well.


> Unless there
> is some serious discipline imposed, it will probably mean that the
> version of the client in the Apache project will lag the most current
> version.
>
> > Why SHOULDN'T clients pertaining to ESME not be part of ESME.    I would
> > think that interacting with ESME is pretty important.   Getting client
> > developers on board with the project is probably a good thing.  It can
> > get more people using ESME and thus new ideas and such.
> 
> Truly, I think clients are separate programs and projects. I'm not
> sure how Apache deals with these. A quick survey of CouchDB and
> ActiveMQ (two Apache projects I'm familiar with and which have lots of
> clients) shows that most of their clients are not part of the Apache
> project, though some are.

Again, it's completely up to the projects and the oversight that a project is 
able to provide to the client (or other sub project type things).    Another 
example is things like Maven plugins.   SOME plugins are at Apache as the 
Maven project has the ability to provide proper oversight.   Others are at 
mojo.codehaus.   Others are elsewhere.      ActiveMQ and QPid are very 
similar.    The clients that the project can "support" are at Apache.   If the 
communities grow to be able to provide additional clients, they may bring 
others in.

Maven is actually a good example of something else I want to mention.   A 
person does NOT have to be an expert in all things ESME to be a committer.   I 
am a committer for Maven, but I've never committed anything into the "core" of 
Maven.  I haven't even looked at much of the core code.    I was voted in due 
to my work on several of the Maven plugins.   The maven community thought that 
my contributions in those areas were valuable enough to the maven community to 
grant committership (and later voted in to the PMC as well).

If there were smaller things that people could align themselves with and 
become "experts" in that area, it may be easier to attract new committers in 
those areas.   Attracting new committers is an important part of the community 
building required for graduation.  


> It seems this is an area of project governance we need to discuss,

Yep.  Agreed.   Basically, from my standpoint, does ESME at Apache want to be 
"THE COMMUNITY" for all things ESME (that it legally can, the SAP legal issue 
is obviously an issue) or does it just want to be the community for the "core 
ESME server" with extra value things being delegated out to other communities?   

That's a VERY good thing to discuss and also affects the charter that would 
need to be written upon graduation.


Anyway, with ESME being in the incubator, one thing you have to also think 
about is "what do we need to do to be ready to graduate?"    Growing the 
community is one important aspect, but finding ways to do that is sometimes 
hard.   (getting a release out is also important... any progress?  ;-)   )


Dan


> hopefully with guidance from the mentors about what the normal
> approach is for Apache projects.

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message