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:46:56 GMT
On 2/1/02 5:30 PM, "Scott Sanders" <ssanders@nextance.com> wrote:

>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Friday, February 01, 2002 2:17 PM
>> To: Jakarta Commons Developers List
>> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release
>> 
>> 
>> 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".
> 
> By cohesive, I would hope to mean that if you've used one, you could
> easily use another with a minimal amount of trouble...

How would that come about? They fit into a common framework or something?

> 
>> 
>>>> 
>>>> 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?"
> 
> The JK means Just Kidding :)

Ah :)
 
>>  
>>>> 
>>>>> 
>>>>> 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?
>>  
>> ;)
> 
> With another PMC and everything? :)  How many levels of abstraction do
> we need to code?  We need the ASF and the ASF Board to protect us from a
> corporate perspective, and then there should be the coders.  That should
> be it.

Or create a "Commons" project in Jakarta where components had a home....

 
>> 
>>>> 
>>>> 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 :
> 
> Committer status to inactive committers.

Oh.  That's easy, isn't it?

> 
>> 
>> 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.
> 
> OK, but I do not see how this makes the situation better.

Then the normal meritocray of Apache/Jakarta applies to the components, and
peter can't add his name to the STATUS file :)
 
>> 
>> 
>> 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 just don't agree that there is a problem...

Ok.

>>  
>>>> 
>>>>> 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...
> 
> I started out in Jserv, and was too scared to ever make enough patches
> to be a committer, but I got over it...  I really like jon a lot
> *because of* how he conducts himself.
> 
>>  
>>>> 
>>>> 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 :)
> 
> This is the case?  This is good.  What counts as activity?  Do you have
> a URL?
> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> 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.
> 
> As Costin said, anything is possible, but probable is a different thing.

So you believe that all people share the same point of view when it comes to
format, writing style, POV and such for javadoc?  These are the same people
that can't agree where the curly bracket should be placed on an if() block?
 
>>  
>>>> 
>>>> 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 :)
> 
> Or would it be?

Of course!  Has there been any suggestion from me other than just tightening
up component committer status from 'add to a file' to 'merit-based community
decision'?

Geir

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