The end of stopgaps

[Nathann Cohen]

Just to keep everybody aware of what is going on here:

- I tried to add a stopgap on a code that returns wrong results

- The stopgap was refused because it was "just before a stable
release" and people did not want to alarm the users by telling them
that Sage returns wrong results (even though it does)

- Jeroen noticed that if we add the stopgap now, the same thing may
happen for the next release cycle (as we are not sure that it will be
fixed in the meantime)

- Thus, they now decide that we will not add the stopgap at all. Ever.

So, no stopgap. Let us not tell the users that we return wrong
results. Let them deal with the consequences.

This enlightening conversation showing how trying to preserve our
public image can ruin a good software is available there:

http://trac.sagemath.org/ticket/19302#comment:27

Nathann

[kcrisman]

I will note that sometimes stopgaps are harder to implement than in other cases.  For instance, sometimes integrals returned are wrong; but then again, they likely always will be (and not just in Sage/Maxima) so it's hard to imagine having every single use of integration return a warning.  But I may be in the minority in this opinion.  I don't know the context from the ticket you refer to, of course.  That said, I think just before a stable release is probably the *best* time to add a stopgap, since it's unlikely it will be fixed in the last rc :)

[Jakob Kroeker]

At least a user could look at the list of bugs silently producing wrong answers:

http://trac.sagemath.org/report/79

I updated the list by manually looking at open tickets from #1 to #13345
and adding a stopgap marker 'todo' if required.

Remaining task (I will do that):
check open tickets #13346 to #19383 for issues silently producing wrong answers
and add them to the list http://trac.sagemath.org/report/79


Jakob

[Nils Bruin]

On Friday, October 9, 2015 at 1:29:14 AM UTC-7, kcrisman wrote:

I think just before a stable release is probably the *best* time to add a stopgap, since it's unlikely it will be fixed in the last rc :)

Indeed, making an invasive change in an rc which probably causes widespread and hard to predict changes in behaviour (there is a lot of behaviour in sage that depends on enumeration order of dictionaries and hence on exact hash values) is probably not a smart move.

A stopgap message should have some diagnostic value, however. In this case, the message would probably be triggered quite early on, in an unavoidable case, where the current hash is fine to use. A subsequent use of the hash in a case where its use should really be disallowed would remain unmarked. We might as well add to the banner "disclaimer: sage still has bugs".

That said, Vincent and I are basically done with removing the default hash (we identified the problem with the last doctest), so I expect 6.10 will not have this problem anymore--unless unexpected problems surface. It's nice that people care about proper procedure to let sage "do the right thing", but it's worth keeping in mind that effort spent on procedure is effort not spent on actual progress.