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 22:16:52 GMT
On 2/1/02 4:54 PM, "Scott Sanders" <ssanders@nextance.com> wrote:

>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> 
>>  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?
> 
> Not a framework, but hopefully a cohesive set of independent reusable
> components.  Creating a generic component is as much of a singular
> mindset as creating an entire framework.
> 

Ok - describe what you mean by 'cohesive'?  I don't understand the phrase
"cohesive set of reusable components".

>> 
>> Because they are very small and then Jakarta would become
>> more confusing to the outside world than it already is.
> 
> I think that has already happened IMHO.

To some degree, I 100% agree.
 
> Why stop now?  JK, I think that we could help in this area, somehow,
> someway ;-)

Are you serious about the "Why Stop?"
 
>> 
>>> 
>>> 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...
> 
> I can agree with this, yet for some reason I still resist :)

Yes - I understand that...
 
>>  
>>>> 
>>>> 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...
> 
> Already there, IMHO.  At least if we added hundreds more, the problem
> would *HAVE* to be solved.

Yes, like maybe having a project that is a container for the smaller
components?
 
;)

>> 
>> 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.
> 
> OK.  It's whole agree, but disagree thing.  I agree with you, but I also
> think that some sort of commit status deprecation needs to take place,
> in order to truly make this type of community work.

Deprecate what?  Here's one approach :

1)  Freeze committer status as to what is in the STATUS files,  pre-Peter :)

2) If you are a committer in a component, you are a commons committer.

3) If you are a commons committer, your rights and responsibilities include:
  a) sandbox commit rights
  b) The responsibility to vote on new components being added to commons - I
think the group dynamic is important in shaping the overall 'flavor' of
commons going forward.

4) You can be added as a sandbox committer independently of commons, to let
strangers in to start contributing immediately either with new things, or
collaborating fully on things existing in sandbox.


I don't think the above is in spirit or letter a radical departure from what
we have now.  It just tightens up the problem that we knew about and Peter
effectively demonstrated.

 
>> 
>>> 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.
> 
> Yeah, but just because I was afraid of Craig ;-)

We all are at some point. ;)

And try starting out by committing to a project with Jon Stevens as an
active committer :)  and do it by suggesting a feature he is *dead-set*
against.  True test of ones commitment to the idea, I will say...
 
>> 
>> 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.
> 
> Yes.  But, the same problem exists in reverse.  I am a committer to
> Digester, and two years later, after no activity, I veto a release
> because it uses SAX3, and I don't like David Brownell.  This is all part
> of a 'larger' problem.

Nope - two years of no activity, and you aren't eligible to vote :)

> 
>> 
>>> 
>>> 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...
> 
> Maybe.

Sure - I wasn't suggesting that you personally would be that way - just that
you can imagine that it's possible in general.
 
>> 
>> 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.
> 
> Or maybe I see Paulo contributing in several areas, and convince the
> rest of us to make him a committer :)

That's good too.  But you would see that as it's still one big list :)


-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
"The J2EE Compatible brand has achieved significant momentum over the past
two years, and we want to make sure that any open source efforts don't
impact the viability of that effort. "
- Karen Tegan, Director of J2EE Compatibility and Platform Services
 Sun Microsystems


--
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