commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Fri, 01 Feb 2002 22:50:19 GMT
Answer inline:

> -----Original Message-----
> From: Scott Sanders []
> Sent: Friday, February 01, 2002 10:15 PM
> > -----Original Message-----
> > From: Geir Magnusson Jr. [] 
> > Sent: Friday, February 01, 2002 1:04 PM
> > 
> > ...
> > 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.

Life in Avalon is quite different and much less problematic. 
The framework focus seems to enforce a more homogeneous culture
and consensus is easier. (Although there is still a lot of room
for discussion and competing solutions.)

Avalon is not better or worse but it is a very different thing,
with a different nature from the Commons.

The commons looser structure asks for different solutions, 
although I am not sure which those are.

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

Which makes quite some difference from the Avalon style.

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

The sandbox is an important point.

Maybe everybody should have access to the sandbox and maybe we 
should be really selective about what gets out from the sandbox.
Maybe many components should just stay there much longer than 
others because some things take much longer to mature.

However, some projects really need some stability because many 
others might depend on them, and me thinks that such stability
is better served by a stable committer base.

A lot of people say that the commons logging package is not really 
necessary but I bet that a lot of projects will depend on it soon.
What if a committer changes it to suite some specific need without
knowing well the package, its story and the other users/uses of 
the package?

I am not sure that committing rules should be as strict as with 
projects like Velocity, but at least some principles should be
laid down.

And I sure can understand Peter's concern. A lot of other Avalon
code depends on the components that could be moved from Avalon to
the commons... and many other projects depend on Avalon.

What if someone just breaks one of those components?

I have no smart-ass answer for this problem but probably the 
answer is not full bazaar mode, as it probably is not full 
cathedral mode.
> ...

Have fun,
Paulo Gaspar

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message