ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [Bug 7153] - Need additional Microsoft Visual SourceSafe Tasks
Date Tue, 19 Mar 2002 22:35:32 GMT

put bluntly - if you want ant-dev to behave like that then stop complaing and 
start doing. 

For instance before Magesh was a committer he used to go through bug board, 
aggregate patches and clean/report/etc issues that pop up. He then used to 
send the aggregated patches to the mailing list. I vaguely remember him also 
doing refactoring, documentation and unit testing for the patches. 

Eventually most of these patches got applied and he became a committer. 

Feel free to start doing the same.

On Wed, 20 Mar 2002 07:43, Jose Alberto Fernandez wrote:
> From: "Magesh Umasankar" <>
> > 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.
> > 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.
> > 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.
> > 4. Patches that rely on the committer to
> >    perform documentation patches, if any.
> Send them back with a note. But speak about it.
> > 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?
> 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.
> > 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").
> > 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?
> Jose Alberto



 I just got lost in thought... It was unfamiliar territory.

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

View raw message