Before someone spend time rewriting the whole package, wouldn't we want the ability to comment on a skeleton design that might not pass unit tests?
On Tuesday, August 20, 2013, Gilles wrote: > On Tue, 20 Aug 2013 14:55:51 -0700, Ajo Fod wrote: > >> I agree that in general test are necessary to ensure that something useful >> is being accomplished by the submitted code as I'd mentioned in my mail. >> >> I admire the rigour of tests in CM. There was one case where I didn't know >> what needs be tested and I didn't see the point in taking it further since >> I'd copied the code over to a personal package and patched it as I saw >> fit. >> > > Good for you... > > All I'm saying is that sometimes commiters are in a better position to >> judge what needs to be tested >> > > A: Everything (ideally). > Q: What should be covered by unit tests? > > and either suggest tests or even add it if it >> is simple enough. >> https://issues.apache.org/**jira/browse/MATH-999<https://issues.apache.org/jira/browse/MATH-999> >> > > CM is a collaborative work. Please refer to the archive for (re-)reading > what this means (ideally). > > On the subject of this thread: I did not imply that an "experimental" > package would allow sloppy or undocumented code or bypass unit testing. > All (the above) things being equal, the purpose would be to compare > alternative designs. > > > Gilles > > >> Cheers, >> -Ajo >> >> >> On Tue, Aug 20, 2013 at 1:30 PM, Gary Gregory <garydgreg...@gmail.com >> >wrote: >> >> On the point of tests: Considering tests a hurdle is the wrong way to >>> look >>> at it. Tests are the foundation I can confidently build on and change >>> code. >>> >>> Gary >>> >>> >>> On Tue, Aug 20, 2013 at 3:07 PM, Ajo Fod <ajo....@gmail.com> wrote: >>> >>> > My 2c worth. It seems like there is a general bottleneck. A lot of >>> ideas >>> > don't get used because there is a hurdle that people have to make >>> change >>> > that satisfy all code requirements like tests/reuse of blocks etc. This >>> > makes for a larger than necessary hurdle for people to contribute. >>> > >>> > Looks like Gilles tried to solve this problem. One alternative is to >>> place >>> > alternative/new code in a nursery/experimental package parallel to the >>> main >>> > line of code. This nursery code wouldn't be subject to the deprecation >>> step >>> > or stability guarantees. The nursery packages should be better than the >>> > main line of code or solve an unsolved problem demonstrated with >>> > appropriate tests. >>> > >>> > That way, users will be aware of and can benefit from the ability to >>> solve >>> > a problem in CM. This will also be "advertisement" for the needed work >>> to >>> > include the work in the main line of code. >>> > >>> > Cheers, >>> > -Ajo >>> > >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition< >>> http://www.manning.com/bauer3/**> >>> JUnit in Action, Second Edition >>> <http://www.manning.com/**tahchiev/<http://www.manning.com/tahchiev/> >>> > >>> Spring Batch in Action >>> <http://www.manning.com/**templier/<http://www.manning.com/templier/> >>> > >>> Blog: http://garygregory.wordpress.**com<http://garygregory.wordpress.com> >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
