From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]> > > From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]> > > > > 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 patch. > > 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 up. > 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 Cheers, Magesh ************************************************* * Politician: One who shakes your hand before * * elections and your confidence after. * ************************************************* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
