Thanks for the additional explanation, Platonides.
git bisect can handle merge commits, but I have run into problems with it -- but it may also have been my weak git-fu. FWIW, I was able to linearize history using git rebase on a local branch -- I had to resolve a couple very minor merge conflicts, but the rebased repo is identical to the current repo - so that is an option to consider if/when someone runs into git bisect issues.
Anyway, apologies for the temporary hijacking of the thread. I am done with the non-linear history bit for now.
Back to the more important issue of the bug itself.
Subbu.
The problem is that we can't reproduce it. Otherwise we would have already found the problematic commit (yes, git bisect would be able to).
It probably only happens with lagged slaves and many people editing at the same time.
I have already studied the commits in that range, but none of them seems likely to have produced the bug. :(
As we can detect it easily on big wikis (such as enwiki) what we could do is to (a) rollback enwiki to such version, (b) verify it got fixed (ie. it's a mediawiki core/extension bug), (c) advance bisecting to the next wmf release. Yep, bisecting in the live cluster. That's far from ideal, but not being able to find it otherwise, that _should_ reveal it.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l