Max Horn [off-list ref] writes:
On 17.03.2014, at 18:01, Junio C Hamano [off-list ref] wrote:
quoted
Torsten Bögershausen [off-list ref] writes:
quoted
On 2014-03-14 23.09, Junio C Hamano wrote:
quoted
* ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
- remote-hg: do not fail on invalid bookmarks
Reported to break tests ($gmane/240005)
Expecting a reroll.
I wonder what should happen here.
The change breaks all the tests in test-hg-hg-git.sh
(And the breakage may prevent us from detecting other breakages)
The ideal situation would be to have an extra test case for the problem
which we try to fix with this patch.
Antoine, is there any way to make your problem reproducable ?
And based on that, to make a patch which passes all test cases ?
After re-reading the thread briefly (there're just five messages)
http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069
For some reason, that link does not contain all messages from that
conversation (unfortunately, I have seen GMane do that on multiple
occasions. I hence try not to rely on it for reviewing email
history -- I just don't trust it). In particular, it misses this
crucial post:
[jc: please avoid overlong lines; I re-flowed above]
http://thread.gmane.org/gmane.comp.version-control.git/239830
Interesting.
The (or at least "a") root cause has actually been
discovered. Would a patch that adds an xfail test case for it be
acceptable?
Do you mean a patch that only adds a new test that expects a failure
to the current code, without touching the current code that has the
bug it exposes? That would be a good place to start.
... As a matter of fact, I a know a few more bugs in remote-hg for
which I could produce xfail test cases. Of course I'd prefer to
put them in together with a fix, but I don't know when I can get
to that, if ever. So, would such changes be welcome?
Surely. That is to keep tabs on bugs in an actionable form; it is a
better way of bug tracking than having a bug-tracker that is not
actively maintained, I would think.
Am 19.03.2014 um 18:04 schrieb Junio C Hamano [off-list ref]:
Max Horn [off-list ref] writes:
quoted
quoted
On 17.03.2014, at 18:01, Junio C Hamano [off-list ref] wrote:
Torsten Bögershausen [off-list ref] writes:
quoted
quoted
On 2014-03-14 23.09, Junio C Hamano wrote:
* ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
- remote-hg: do not fail on invalid bookmarks
Reported to break tests ($gmane/240005)
Expecting a reroll.
I wonder what should happen here.
The change breaks all the tests in test-hg-hg-git.sh
(And the breakage may prevent us from detecting other breakages)
The ideal situation would be to have an extra test case for the problem
which we try to fix with this patch.
Antoine, is there any way to make your problem reproducable ?
And based on that, to make a patch which passes all test cases ?
After re-reading the thread briefly (there're just five messages)
http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069
For some reason, that link does not contain all messages from that
conversation (unfortunately, I have seen GMane do that on multiple
occasions. I hence try not to rely on it for reviewing email
history -- I just don't trust it). In particular, it misses this
crucial post:
[jc: please avoid overlong lines; I re-flowed above]
Sorry. If anybody knows a way to tech Mail.app to auto-wrap
long lines, I'd appreciate a hint.
quoted
http://thread.gmane.org/gmane.comp.version-control.git/239830
Interesting.
quoted
The (or at least "a") root cause has actually been
discovered. Would a patch that adds an xfail test case for it be
acceptable?
Do you mean a patch that only adds a new test that expects a failure
to the current code, without touching the current code that has the
bug it exposes?
Exactly.
That would be a good place to start.
Ok.
quoted
... As a matter of fact, I a know a few more bugs in remote-hg for
which I could produce xfail test cases. Of course I'd prefer to
put them in together with a fix, but I don't know when I can get
to that, if ever. So, would such changes be welcome?
Surely. That is to keep tabs on bugs in an actionable form; it is a
better way of bug tracking than having a bug-tracker that is not
actively maintained, I would think.
Yeah, makes sense.
So, one more silly (bikeshedding) question: should I do this as one big
patch adding multiple xfail tests - or one commit per test, with perhaps a
brief description of the issue at hand? Or should a code comment next to
the failing test explain things?
Actually, some of those bugs might require a lengthy background
explanation, so yet another variant would be to write an email here
With an explanation, then add a gmane ref to the commit message...