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

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.

> 
> > 
> >> 
> >> 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 think that has already happened IMHO.  

Why stop now?  JK, I think that we could help in this area, somehow,
someway ;-)

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

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

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

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.

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

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

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

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


Scott

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

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