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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
