commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Fri, 01 Feb 2002 22:30:45 GMT
> -----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...

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

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

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

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

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

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

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

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

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