Hi Michael, Awesome to see you are still working on that tool. It's enough outside of the box, I can see it can cause other people without context to become confused. But I think we will learn something from it, whether it will ultimately work perfectly or not.
On the specific question: "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." - I think for now it is better to leave this question aside. I would focus on making it's original goal work and only then to focus on side-benefits. MVP and all that. Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 7 December 2014 at 08:52, david.w.smi...@gmail.com <david.w.smi...@gmail.com> wrote: > Michael, > I recall you’re working on building a test tool that sees changes and runs > applicable tests? If that’s the case, why would it matter if CHANGES.txt > gets updated? 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. So your tool would see a commit and run the > subset of applicable tests based on some sort of source-code dependency > graph; right? Of course for many parts of Lucene, that will trigger all > tests being run. 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. > > ~ 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
