ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: What is going on in ANT1.x
Date Thu, 07 Feb 2002 03:02:27 GMT
On Thu, 7 Feb 2002 12:53, Jose Alberto Fernandez wrote:
> > > One of the problems I see, is that when code gets put in by
> > > committers, in very few occacions other review the code.
> >
> > I hope (and believe) that this is not true.

I think this is partially true but I don't really see it as a problem. People 
become committers of ant for a number of reasons - one of the most common 
reasons being that they inundate people with high quality patches (hi 
Magesh!) that ant-dev gets sick of committing ;)

So yes committers get less review than non-committers but thats mainly 
because they have earnt a higher level of trust. Sometimes things get botched 
- this is true and some things turn out to be bad ideas in retrospect. If we 
had a clearer separation between container/api/framework/tasks then it would 
be much easier to monitor the more important bits. ie It is most iimportant 
to monitor API changes, then framework changes, then container changes and 
then finally tasks. Its not the case now but hopefully it will be in the 

A lot of the changes can be auotmagically reviewed by audit, metric and 
dependency tools. I am also planning to integrate in JDiff (differences 
between different versions of source is generated and tracked - used in many 
JSRs to track evolutions of specs. If the code passes all those tests then 
the committers and other community members can review the code as they want.

> I think the same thing happens with committers written code. We trust you
> guys and therefore I do not think people are so keen at doing codes
> reviews. The code is already in and hence unless you can come up with an
> evident issue, it is difficult (at least for non committers) to do anything
> about it.

No it isn't. If you think something is wrong then say it but MORE importantly 
send a patch that corrects it. Keep sending patches until all the issues are 
fixed. This is a great way to get other committers attention to look at the 
area aswell ;)

> As an example, like 2 month ago or more, Peter made a change in ANT2
> where it rename getTaskName() to getName(). At that time I mentioned
> that by doing that it may cause a conflict on tasks, but since it was not
> obvious at the time the change stayed. A few days ago, another change was
> introduced for what it seem to be exactly the kind of issues I was refering
> about. Maybe he was aware of this from the begining, may be not. But the
> point of the matter is that once it is committed, the burden is on those
> that think that soomething is not quite right. Which is different than for
> non-committers.

Im not sure I am exactly aware of this particular issue. I think what you 
mean is that I made a lot of helper methods in AbstractTask that looked 
something like

protected final void doMagic()

However bunches of these doMagic() were getters or setters which already used 
as a pattern in tasks so I had to inline the method calls and replace them 
with the explicit getContext().doMagic().

Is that what you mean? If so I was aware of some of the problems (setters) 
but the other problems only became obvious when I was implementing stuff.

Now if you had instead sent a patch saying X sucks, heres the fix. I would 
have gone - ahhh! and applied the fix :) The important part is sending the 

You may be surprised to know but at one stage I really wanted to bring you on 
as a committer - and this was despite the fact that I disagreed with you on 
fairly major things. I figured if you could translate your energy for 
argument into energy for coding you would make a great addition to ant-dev.

The problem was mainly that you had not sent any patches and thus it was felt 
that it would be not appropriate to nominate you - or it could be that they 
wanted to avoid fireworks between you and me ;)

Anyways the way your opinion gets taken notice of is via sending patches. You 
think something is wrong then correct it and send a patch. In the case of 
Ant1.x there are some areas that are almost out of bounds and compatability 
is always a monkey on the shoulder however that does not preclude rewriting 
and replacing stuff. 

If you want more freedom or want to do something with a more experimental 
flair then you can start a proposal dir like proposal/rjunit or whatever and 
start ending patches for it.

If you want to contribute to the next generation of ant then start proposing 
stuff and prototyping it. We would love to have your opinion on myrmidon and 
feel free to send patches etc ;)

Bottom line is Apache is mostly a meritocracy. The more patches/code/whatever 
you contribute the more likely your opinion is going to effect the outcome of 



 Don't take life too seriously -- 
                          you'll never get out of it alive.

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

View raw message