ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: [Bug 7153] - Need additional Microsoft Visual SourceSafe Tasks
Date Tue, 19 Mar 2002 22:08:27 GMT
From: "Jose Alberto Fernandez" <>

> > From: "Jose Alberto Fernandez" <>
> > 
> > What frustrates me as a committer:
> > 1. Bug reports that are not proven as
> >    bugs (using Junit tests).
> For this to happen, it means that every ANT user needs to download
> the sources from CVS to get the test framework for ANT.
> It needs to understand the framework (not easy). Never mind
> being aware and understand JUnit. (Not something that every
> user needs to know). 
> I think this is a very hi mark. If you say, submit a buildfile
> that shows the problem, well that is a different issue.

If you want your patch to be applied 
fast, then you need to reach that hi mark.
Or else, wait in the queue till some
committer takes it upon himself to write
testcases, docs, and other missing pieces.  
Obviously, this is gonna take some time.

> > 2. Patches to bugs/enhancement requests
> >    that do not contain Junit tests that 
> >    prove that the patch fixes the bug, by 
> >    providing JUnit tests that fail before 
> >    patch is applied and pass after patch 
> >    is applied.
> I have no problem with this in principle. But again I think a
> buildfile showing the problem should be enough. After all
> external users do not need to learn our automated QA
> before they can do something.

Even reporting the problem is enough!  I don't
expect every Ant user to even know how to submit
a patch.

But if somebody submits a patch and complains
that it never gets committed, well, then, either
wait or push for it by being 'complete' with the

> > 3. Patches that do not care about backwards
> >    compatibility.
> How many of those have been rejected officially
> anotated on Bugzilla and indicating to the submitter
> what the problem is? You cannot assume that everyone
> in the world has the same mindset as the submitters
> about Java 1.1. I mean how many people rememner any more
> whether this or that API was in 1.0 or 1.1.
> This is why you guys are committers and the rest are not.

Backwards compatibility wrt Ant itself,
not the JDK (which is relatively easy to
find out by compiling using JDK 1.1).
If you refactor some code, or fix some
code, is it being backwards compatible to
previous Ant releases?

> > 4. Patches that rely on the committer to
> >    perform documentation patches, if any.
> Send them back with a note. But speak about it.

It is being done (at least I do it).  But
again, this need has been well documented as a 
guideline.  No need to keep re-iterating the 
fact that we need a document patch as well - that 
is a waste of my time, I think.

> > 5. Patches to tasks that I cannot compile
> >    myself or execute myself because of
> >    dependencies on external tools.
> > 
> So what do you want, that people do not try to fix things?

No, of course not!  All I was saying was that
it is frustrating for me because even
if the patch is good, I am not in a 
position to test it out before committing 
it.  If users find such patches in bugzilla
useful, they must vote for it.  Perhaps somebody
who is comfortable committing it will pick it 

> This is one of the reasons I have pushed so much for <antlib>
> because this problem is due to the complete lack of modularity
> of the current source. Once ANT-DEV accepted those tasks
> in the first place, you are stuck with it, unfortunately.

Such tasks were obviously committed by
somebody - if that person is still active,
best bet is to ask him/her to take a look at
the patch.  Otherwise, I don't have a really 
good answer.

> > I know it may be asking for a lot, but, if the
> > patch contains lots of tests, documentation
> > patches and the code patch as well, it would
> > get committed faster.
> > 
> But if you were to anotate the bugs with what you think is missing,
> then maybe you will get the missing things sooner. Maybe we need
> additional states for a bug (e.g., "Incomplete PATCH Submission").

What makes up a good patch is pretty well 
documented.  When I come across patches that
miss some of the things, I have been pointing 
them out...

> > With all this said, I did do a sweep
> > of BugZilla patches a month or so back, 
> > IIRC and applied all of those that
> > I was comfortable with - so I would say 
> > patches haven't been lingering there for 
> > a very long time.
> > 

> Did you tell the submitters the problems you found on the other bugs?

No, because the problem was I was not in
a position to work on those patches - they
were related to some optional tasks using 
tools and APIs which I don't have access to 
in my environment.

> Jose Alberto


*  Politician: One who shakes your hand before  *
*  elections and your confidence after.         *

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

View raw message