25

The consensus for handling posts about fixed bugs was to include a line stating in which version the bug went away.

I would like to propose taking this one step further, and standardizing the header of bug-posts. This will serve the purpose of making it easier to search for bugs based on status or version, both for regular site users and for Wolfram.

I suggest keeping to the following rules:

  • the information should be added as the very first line
  • if and only if the bug is fixed in the latest version, it should contain the word fixed somewhere

These two criteria are already satisfied for most posts, so they won't create an unnecessary maintenance burden. See an example.

Thanks to this, @Pickett was able to create a tool that makes it easy to search for bugs by status. It outputs an interactive HTML page that looks like this:

enter image description here

Notice that it also extracts the header line when it detects the word fixed. It would be even better if it could also detect headers without this word based on some other cue word.

I am awaiting for proposals for an easy-to-copy standardized header. We should not be so naive as to expect that everyone will rigidly keep to this template (which is why I only suggested the two simple rules above as strictly necessary), but having a template to refer users to will make things work more smoothly.

| |
  • 1
    We need a Natural Language Search Engine! – Silvia Jul 25 '15 at 1:59
  • The links to Pickett's bug tool in chat are dead. Does the tool still exist and is there another link to it? – Michael E2 May 17 '17 at 12:20
  • 1
    @MichaelE2 Here's a new example page (not kept up to date although it says it is), and a new link to the source code. – C. E. May 17 '17 at 17:24
  • @C.E. Thank you. – Michael E2 May 17 '17 at 18:57
22

I have been using this format:

Bug introduced in X.X and fixed in X.X.X

with MarkDown code

**Bug introduced in X.X and fixed in X.X.X**

And for open-ended versioning:

Bug introduced in X.X or earlier and persisting through X.X.X or later

with MarkDown code

**Bug introduced in X.X or earlier and persisting through X.X.X or later**

I chose not to use minor version number for the introduced mark as often that is not quite certain. (People may keep earlier versions installed but usually only the last point release.)

| |
  • I have been using the same format, except opting in some cases for the Bug fixed in X.X.X variant. Would that be acceptable? – ilian Jul 24 '15 at 22:40
  • 1
    @ilian That would still let one search for e.g. "fixed in 10.2.0" so I think it should be fine, but where possible I think it would be quite helpful to know when a bug first appeared and I assume you are in a better position than most to add that information. – Mr.Wizard♦ Jul 24 '15 at 22:43
  • What about reappearing bugs? I seem to recall that we had some. – Sjoerd C. de Vries Jul 25 '15 at 22:16
  • @Sjoerd Can you find more than one or two? If so we may need to take that into consideration. If not it's probably rare enough to handle exceptionally. – Mr.Wizard♦ Jul 25 '15 at 22:35
  • Ok, I couldn't find any at the moment. – Sjoerd C. de Vries Jul 25 '15 at 22:53
  • 1
    If an issue reappears (hopefully very rare), then I would suggest adding a second line (leaving the first line). – Arnoud Buzing Jul 27 '15 at 21:48
  • For completeness, what format do you suggest for bugs introduced | present since the current Mathematica version. – Karsten 7. Jul 28 '15 at 14:50
  • 3
    @Karsten7 You mean like a bug introduced in 10.2.0? I would favor simply Bug introduced in 10.2 -- not until we have a version past that would additional notation be useful, IMHO. – Mr.Wizard♦ Jul 28 '15 at 15:27
  • 1
    @Mr.Wizard got one: mathematica.stackexchange.com/questions/89686/… with mathematica.stackexchange.com/questions/54658/… – Sjoerd C. de Vries Aug 2 '15 at 7:46
  • @Sjoerd One might argue that it is not the same bug, only the same effect. But a good test nevertheless. This deserves more thought. – Mr.Wizard♦ Aug 2 '15 at 8:06
  • I guess one might consider it as a separate bug, but cause and effect are so similar that I would suggest treating them as one, at least in this case. – Sjoerd C. de Vries Aug 2 '15 at 8:20
  • I am not sure about the persisting through X.X.X or later part: while it can provide useful information, maybe a bug should either be fixed and marked so, or else assumed implicitly to be persisting through the most recent version. – ilian Aug 2 '15 at 21:55
  • @ilian The issue is this: if that information is not included in the header no one will know which versions have been tested and which have not, therefore people may/will/should need to keep checking to see if it has been fixed yet. With the proposed header one can see "through 10.2.0 or later" and know that the most recent version has already been checked. Can you think of another way to handle this? – Mr.Wizard♦ Aug 2 '15 at 22:07
  • I think having that part in the header (as opposed to elsewhere in the question or comments) also implies more maintenance. After the next few versions are out, it may not be incorrect (since it says or later) but would also be less meaningful without further checking. – ilian Aug 2 '15 at 22:27
  • 1
    @ilian When a new version is released further checking is exactly what is needed, but hopefully only once. Keeping this information in the header maximizes visibility so that one does not have to dig to figure out if someone else has already checked the new version for the bug or not. Pardon me if I am missing your point. – Mr.Wizard♦ Aug 2 '15 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .