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:15:15 GMT
> -----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.

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

I believe the group dynamic of many committers, some not knowing the
code of certain projects, serves to try and KEEP the components generic.

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

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

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.

> 
> geir
> 
> 
> (*) I have no idea what 'small' really means :)

Understood.  I thought Tomcat was 'small' ;-0

Scott

> 
> > 
> > Let a person's code speak.
> > 
> > Scott
> > 
> >> -----Original Message-----
> >> From: Peter Donald [mailto:peter@apache.org]
> >> Sent: Thursday, January 31, 2002 12:05 PM
> >> To: Jakarta Commons Developers List
> >> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release
> >> 
> >> 
> >> On Fri, 1 Feb 2002 05:06, Scott Sanders wrote:
> >>> What needs to be changed Peter?
> >> 
> >> People who dont contribute to a component dont get voting 
> rights over 
> >> a component.
> >> 
> >>> Explicitly state it in a
> >>> proposal/vote/patch and let's do it.
> >> 
> >> I have proposed it several times before. If you go back to the 
> >> original vote for commons you will see that I only started 
> waving the
> >> Avalon duplication
> >> flag after I was ignored on this issue for the second time. I
> >> had hoped Jon 
> >> would have picked up on it and we could have forced the
> >> proposal to include
> >> this requirement but it didn't happen this way.
> >> 
> >> --
> >> Cheers,
> >> 
> >> Pete
> >> 
> >> ---------------------------------------------------------------
> >> The difference between genius, and stupidity? Genius has limits
> >> ---------------------------------------------------------------
> >> 
> >> 
> >> --
> >> 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>
> > 
> 
> -- 
> Geir Magnusson Jr.                                     
> geirm@optonline.net
> System and Software Consulting
> Be a giant.  Take giant steps.  Do giant things...
> 
> 
> --
> 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