Hi Alex Am 07.12.14 um 14:59 schrieb Alexandre Rafalovitch: > 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.
yes, I hope we all can learn from. I have learned a lot already and I hope I will be able to return something > > 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. I am sorry that I caused some confusion with my question regarding CHANGES.txt. I guess you are right, it is better to focus for the moment on the existing functional tests, which I will try now. Thanks Michael > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
