Did you read the issue at all?
You have to run the test thousands of times with a particular random
seed to have a chance of reproducing.
On Sun, Dec 7, 2014 at 5:19 AM, Michael Wechner
<michael.wech...@wyona.com> wrote:
> Hi Robert
>
> Thanks very much for your feedback. I guess you mean the following change:
>
> git diff
> 1f69438a17a0ad33bb9c209113b0fe83fb68f860..5bb9e0aebe18a67e5e0e4698e0553d6824327495
> lucene/core/src/java/org/apache/lucene/index/IndexWriter.java
>
> - assert lastCommitChangeCount <= changeCount:
> "lastCommitChangeCount=" + lastCommitChangeCount + " changeCount=" +
> changeCount;
> + if (lastCommitChangeCount > changeCount) {
> + throw new IllegalStateException("lastCommitChangeCount=" +
> lastCommitChangeCount + ",changeCount=" + changeCount);
> + }
>
> right?
>
> I really did not mean to point fingers, but I just try to think of a
> "testing environment" which assists developers as good and as efficient
> as possible to find things which might have been forgotten or maybe
> break something.
> I think the above is a good example how difficult it can be to do this,
> but still I think it is possible and would help us all.
>
> Hence I would like to ask again, what is the general rule for updating
> CHANGES.txt
>
> About missing tests, I guess you experienced a buggy G1GC collector or
> other JVM bugs and hence you
> made this change, right? If so, I guess you will run the new code with
> the existing buggy G1GC collector
> and if an IllegalStateException is being thrown, then you will know that
> something is wrong, right?
> Or if I misunderstand, can you explain a bit more?
>
> Thanks
>
> Michael
>
>
> Am 07.12.14 um 10:29 schrieb Robert Muir:
>> Look at the actual change in question,
>>
>> It is not "missing" tests and cannot be tested.
>>
>> It is a guard against jvm bugs like buggy G1GC collector.
>>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
