commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: [Logging] [VOTE] Commons Logging 1.0 Release
Date Fri, 01 Feb 2002 21:48:52 GMT
On 2/1/02 4:15 PM, "Scott Sanders" <ssanders@nextance.com> wrote:

>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Friday, February 01, 2002 1:04 PM
>> To: Jakarta Commons Developers List
>> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release
>> 
>> 
>> On 2/1/02 3:43 PM, "Scott Sanders" <ssanders@nextance.com> wrote:
>> 
>>> How do you enforce this?  How do you handle this in the
>> Avalon world?  
>>> I consider (only just recently, BTW), that a committer in
>> Commons is a 
>>> committer to the entire commons codebase, including the sandbox.
>> 
>> And that's the problem that I think peter is pointing out -
>> that people can have binding votes on projects that they have
>> nothing to do with...
> 
> Peter probably has nothing to do with some of the server components in
> Avalon, but he has a binding vote for them.  How is that resolved?  That
> is the same problem.

 I don't know enough about Avalon and Peter's role.  Doesn't seem to be the
same problem if they are making a coherent server framework.

We aren't, right?

> 
>> 
>> One of the motivations for commons was a place for small*,
>> discrete components to be able to be packaged and presented
>> for reuse by both Jakarta projects and developers at large.
> 
> Yes
> 
>> 
>> So to me, it was to be a container for 'mini-projects', each
>> behaving like any of the other top level projects in jakarta:
>> Each had a user community, each had documentation (hopefully
>> like the other components :), and each had committers that
>> were committers because they showed interest, dedication and
>> provided value.  Now, that the user communities overlapped,
>> and that the developers overlapped didn't matter - in fact,
>> that made the whole model stronger because it coupled what
>> appeared to be islands together into a more cohesive group.
>> Further, the sandbox was added to offer a completely open
>> place for anyone to play, test, experiment and most
>> importantly, collaborate.
> 
> Container for mini projects: Yes.
> Behaving like other top-level projects: No.  If this was the case, why
> wouldn't they just be top-level projects?

Because they are very small and then Jakarta would become more confusing to
the outside world than it already is.

> 
> I believe the group dynamic of many committers, some not knowing the
> code of certain projects, serves to try and KEEP the components generic.

The community dynamic wouldn't change.  Anyone interested would almost for
certain be able to become a committer in anything they chose...
 
>> 
>> However, that's not how it finally turned out.
>> 
>> I too believed then and still believe now that we would be
>> better served with the conventional Apache/Jakarta committer
>> model in Commons, where each component is a well defined
>> group of interested people, a part of the larger community as
>> well, of course.
> 
> But, then again, why not just create top-level projects whose clear goal
> is to do 'x'?

Too many of them.  Hard to manage, hard to present...
 
>> 
>> I don't think there is *any* downside to that model, as
>> people who are committed and interested and want a role in a
>> component will get involved in what I understand the
>> traditional Apache/Jakarta way is...
> 
> There is not a downside to that model, IMHO.  That would have worked
> fine as well.  But I do think that Commons has an advantage with the
> sandbox and the diverse group of committers.

Both of which you would get with the common model - everyone has rights in
the sandbox (it's one singular CVS) and they are still as diverse a
community as they are now.

> I started here because of
> my interest in CJAN, and then Digester.  Now I have great interest in
> 'lower-level' components like io, codec, and util.  I see no problem in
> the current model of just 'jumping over' to do this.

Right, and IIRC, you made contributions to Digester gradually with
increasing confidence over time on both your part as well as the rest of the
committers to Digester.

So if it was the conventional model, you would have submitted patches, and
then someone would say "Hey, we're sick of applying yuour patches - want to
be a committer?" Or something like that.

> 
> I am not blocking progress of Latka or httpclient.  I do not participate
> over there, but I might in the future.  I would definetly be willing to
> look at a patch for something as simple as JavaDoc.  That's where I
> think the strength of the Commons is.

Except if you do not participate, then you don't have a *clue* what their
intent and hopes re Javadoc are, so you might not be doing them any
favors...

And by jumping in like that, you possibly take away one of the 'activators'
of the community model, non-committer posting patches repeatedly,
demonstrating interest, so the 'regular' committers to the project notice,
evaluate, and then offer committer status to the poster.  If you jump in,
the regular committers might not then interact or notice the contribs from
the non-committer.

> 
>> 
>> geir
>> 
>> 
>> (*) I have no idea what 'small' really means :)
> 
> Understood.  I thought Tomcat was 'small' ;-0

Right - I just didn't want it to appear to be a negative attibute ...

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
POC lives!


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message