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
future.
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()
{
getContext().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
patch.
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
things.
--
Cheers,
Pete
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
