commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Fri, 01 Feb 2002 20:52:35 GMT
Answer inline:

> -----Original Message-----
> From: Steve Downey [mailto:steve.downey@netfolio.com]
> Sent: Friday, February 01, 2002 8:41 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
> 
> 
> OK, I'm not a committer, merely a client, 

I was not a committer until yesterday. I still do not feel the 
personality change thing. Maybe we just remain the same persons.

Anyway, just defend what you believe in. The people here use to 
listen... even when they do not agree.


> but it seems to me that all Peter proved is that he can act 
> childishly. 

Believe me, there is a lot of people here that can do that too. 
Some even do it much better than Peter. But they still tend to 
do good stuff most of the time.


> His position is that he doesn't trust the other committers. 

Do you trust everybody with the committer badge with your code, 
money, car keys and wife???


> He doesn't want his code subject to someone else's criticism. 

Than he should avoid producing so much code for Ant and Avalon, 
where such criticism happens all the time.


> Considering the interdependencies of the commons code, that
> strikes me as a bad idea. 
> For example, suppose someone made a change to beanutils that 
> was disastrous
> for digester. Peter's position is that a committer who happens 
> to be working on digester couldn't -1 the change to beanutils.

If there is a bad change to Velocity that breaks Turbine, the 
Turbiners that are not Velocity committers also can not veto it. 
Same with Cocoon that uses Avalon, with all the projects that 
use Log4J, and so on and so on.

But a project that gets his code broken by an Open Source 
component always has many options:
 - Find the change a great idea and just silently fix things;
 - Sticking to the previous version;
 - Forking the component because they want to evolve it and are
   fed up with the component makers;
 - Just adopting another similar component with nicer authors.

The fact is that if you keep breaking things for the users of 
your component you end up having none and everybody here knows 
that. That is the fact that keeps the component authors from 
messing up too much too fast.

However, if you let just any guy to mess with things they do 
not really understand and changing things that are convenient 
to them but are not that good for other users they do not know 
about... chaos reigns supreme.

So, I agree with Peter: the commons will get too big and has a 
too loose structure to control things like this (which is still 
not the case with Avalon).

I am not sure about how strictly one should regulate that, but 
maybe it is necessary.


> I'll admit that it's hypothetical and unlikely, but until 
> Peter -1'd the release of logging (which is a majority vote, 
> fortunately), so was Peter's case of a rogue vetoer.
 
Peter posted that -1 just to defend this POV on the vote rules
and not to avoid the release of logging. If you read that post
with some attention you will see that.


Have fun,
Paulo Gaspar

 
> > -----Original Message-----
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > Sent: Friday, February 01, 2002 8:42 AM
> > To: Jakarta Commons Developers List
> > Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
> > 
> > 
> > Times change. The commons experience is maturing and you made
> > a good point about that issue with that -1 on the logging.
> > =;o)
> > 
> > Just propose it again man.
> > 
> > 
> > Have fun,
> > Paulo
> > 
> > > -----Original Message-----
> > > From: Peter Donald [mailto:peter@apache.org]
> > > Sent: Thursday, January 31, 2002 9: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>
> > 
> <><><><><><><><><><><><><><><><><><><><><>This
electronic mail 
> transmission
> may contain confidential information and is intended only for the 
> person(s)
> named.  Any use, copying or disclosure by any other person is strictly
> prohibited.  If you have received this transmission in error, 
> please notify
> the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
> 
> --
> 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