"Nicolas M. Thiery" <[email protected]> writes:
> On Thu, Jul 19, 2012 at 11:45:09PM +0200, Martin Rubey wrote:
>> two things turned out to be very useful:
>>
>> 1) being able to mark tests as "expected to fail"
>
> That's certainly a nice too, but I would not advocate this in our
> situation, or at least not for patches not in "under review": indeed,
> if we go this way we will end up doing a lot of temporary edits in
> places not necessarily directly related with the patch under
> consideration, and this which will end up creating lots of conflicts.
I am not completely sure I see your point: do you mean, that it is often
the case that a doctest fails because of a *different* patch? And once
that one is fixed, the patch owner would modify his own?
In fact, I would have thought that this makes the second modification
unnecessary (or at least not more necessary than it is now.)
My intended usage was as follows:
A) I author a patch with a doctest that cannot work right now
(eg. because I did not implement something yet), but really should
work in the future (in fact, I usually start with the doctests...)
Therefore I mark it as expected to fail.
doctesting the file will be silent, as long as it fails, but output
doctest expected to fail at line XXX passed
otherwise.
So I'll edit the doctest only if I edit the file. No difference in
noise.
B) I author a patch with a doctest that fails because of some
functionality missing or some bug outside of the scope of this
patch. I mark it as expected to fail.
As soon as the outside world changes, doctesting will output
doctest expected to fail at line XXX passed
I can think of two policies:
1) don't edit.
2) don't edit unless the patch becomes "with positive review".
With current policy, there either would have been no doctest, or the
doctest would fail all along, creating at the very least 10 lines of
noise.
With policy 1, we have no further edits, but much less noise. In this
case I'd say the patch fixing the outside world should contain the edit.
(this should be made *very* clear, otherwise we get conflicts indeed.)
With policy 2, we have possibly 1 more edit. However, in this case I'd
guess there is likely to be a "final edit" anyway, so it should not hurt
too much.
Am I missing something?
Martin
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
