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:49:24 GMT


> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net] 
> Sent: Friday, February 01, 2002 2:47 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release
> 
> 
> 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?

Common build files, javadoc locations, Junit test cases, READMEs, etc.

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

We've got that...

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

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

No, but that's why we do have some rules, IMHO.

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

I was just wondering how much of the Jakarta structure you wanted to
take: cvs privleges, PMC, mailing lists, etc...


Scott

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

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