Hi, 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" <[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. > > > 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 -- Cheers, Pete ------------------------------------------------------------ I just got lost in thought... It was unfamiliar territory. ------------------------------------------------------------ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
