Hi David Am 07.12.14 um 14:52 schrieb david.w.smi...@gmail.com: > Michael, > I recall you’re working on building a test tool that sees changes and runs > applicable tests?
yes > If that’s the case, why would it matter if CHANGES.txt > gets updated? I think in the long term it is not just about the "functional" tests which exist, but about quality assurance in general. Like for example if documentation is being changed, then it would be good to run a spell-checker and in case it is XHTML, then it would be good to check well-formedness and/or the XHTML schema. > The vast majority of the time there is a reference to a JIRA > issue from the commit message, and most JIRA issues that have code > committed to them will wind up in CHANGES.txt. There may be exceptions but > I wouldn’t concern yourself with that. There is an incentive to update > CHANGES.txt where it is appropriate — it’s a place to give yourself credit > as much as it is a place to notify users. thanks very much for clarifying > So your tool would see a commit > and run the subset of applicable tests based on some sort of source-code > dependency graph; right? I think that would be a possibility > Of course for many parts of Lucene, that will > trigger all tests being run. right, but therefore the depedency graph approach might not be the best to start with. IIUC there exists basically a one-2-one connection between classes and tests, e.g. lucene/core/src/java/org/apache/lucene/index/IndexWriter.java lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java or lucene/core/src/java/org/apache/lucene/index/Term.java lucene/core/src/test/org/apache/lucene/index/TestTerm.java So why not start with this very simple obvious approach and then become more complex. > And in some cases, a dependency tool won’t > see code looked-up dynamically using SPI mechanisms like the Analysis > factories and Codecs and Solr PluginInfos. Maybe I misunderstand you, but I think this is where we can describe the relationships/associations in meta files. It will basically contain the information which you as a developer have as knowledge in your brain and this way it will get documented and more accessible to others. Thanks Michael > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley > > On Sat, Dec 6, 2014 at 11:25 PM, Michael Wechner <michael.wech...@wyona.com> > wrote: > >> Hi >> >> Yesterday "morning" I have noticed the following changes >> >> - >> lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java >> - lucene/core/src/java/org/apache/lucene/index/MergePolicy.java >> - >> lucene/core/src/test/org/apache/lucene/index/TestConcurrentMergeScheduler.java >> >> and with these modifications also CHANGES.txt was updated. >> >> Yesterday "afternoon" I have noticed the following change >> >> - lucene/core/src/java/org/apache/lucene/index/IndexWriter.java >> >> but this time CHANGES.txt was not updated (also >> lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java was not >> updated). >> >> As written in a previous email I am trying to test changes incrementally, >> hence I was wondering whether it would be helpful, that such a system for >> incremental testing would also point out things like maybing missing >> updates, like for example for CHANGES.txt or associated tests. >> >> But in order to do so, the system should implement some kind of rule, >> hence I was wondering what the rule is about CHANGES.txt? >> >> I know it sounds a bit like parents saying "hey, have you brushed your >> teeth?!" and it can be rather annoying, but it can also be very useful for >> the future having good teeth :-) >> >> Thanks >> >> Michael >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
