NEW RULE: bug reports using the word “regression” will be ignored

Here’s a fun game. I’ll describe a problem, and you guess whether it’s a regular bug, or a regression!

  1. “This code worked this way before, but now it works differently!”
  2. “A feature I really need was removed!”
  3. “An undocumented feature changed and now my code is broken!”
  4. “The old program had this feature, but its replacement doesn’t!”
  5. “The old program used to do it differently!”
  6. “This thing was broken in the previous release, and it’s still broken!”
  7. “I’m pretty sure it worked this way before, but now it doesn’t!”

Answers:

  1. none of them
  2. seriously none of them
  3. actually, stop saying “regression” altogether
  4. seriously just stop it

So, starting immediately and continuing through all time and space forevermore (no backsies), bug reports that use the word “regression” incorrectly will be ignored.

Here’s a mini-FAQ that should help you understand how to use “regression” correctly:

Q. When should I report a bug as a “regression?
A. Never.

Q. But what about-
A. No. Seriously. Stop it. It’s not a “regression”. It’s just a bug.

Q. But this used to work!
A. I know! It’s frustrating when things change!

Q. But it’s really important!
A. So say “it’s really important” in the bug report!

Q. Should I set the “priority” and “severity” of my bug higher if I think it’s a regression?
A. Sure – we ignore those, too!

Q. You’re joking, right?
A. Of course. We’ve always done it this way.

Q. Is there any time the word “regression” actually applies?
A. Okay, fine. There is one way a bug can actually be considered a proper regression. You need three things:

  1. A specification (not documentation! not a blog post!) that the developers actually adhere to when designing and writing their code,
  2. Evidence that a previous version of the code behaves as described by the spec, and
  3. Evidence that the current code does not behave according to the spec

Q. How often do bugs that claim to be regressions actually turn out to be regressions?
A. This has never happened in the entire recorded history of mankind. Approximately.

Q. Wow. It sounds like “regression” is basically useless in bug reports, and we should stop using it!
A. That’s not a question. But I’ll allow it, because it’s insightful and you’re very handsome.

Advertisements

5 thoughts on “NEW RULE: bug reports using the word “regression” will be ignored

  1. Nah…

    A regression is not means something specific, namely “This was reported as a bug once and fixed once, and now it doesn’t work again”. To claim a regression, all I need is a bug report about the same thing that was fixed in the past; a specification is not required.

    Now, from a developer’s point of view, sure, it would be nice to have a specification of all things that are expected to work – but the fault in not having a specification is with the developer community, not the users. Blaming the users for not writing a specification misses the mark. A regression in a product where the developers don’t have a specification of the product is still a regression.

    • To claim a regression, all I need is a bug report about the same thing that was fixed in the past; a specification is not required.

      Nope. Because if I change something in glibc and it breaks `ls` – even if there wasn’t a bug report about that specific problem before – that’s a regression.

      And really that’s my point – the word “regression” is useless in bug reports because nobody agrees on what it means. And it doesn’t actually change anything about how the bug is handled, so there’s just no point in using it.

  2. Diasgree 🙂

    It’s a bug only if it happens unintentonaly.

    I was going to suggest “priority” and “severity” should be dropped from the interface if not used, then realized Fedora uses the same Bugzilla as Red Hat, good luck saying to a paying customer: is not a regression, your priority and severity doesn’t matter.

    • It’s a bug only if it happens unintentonaly.

      I totally agree! So things like “The new version of this software dropped this feature that I really need!” aren’t regressions. In fact, they’re not even bugs.

  3. I thought regression meant that a bug was re-introduced.

    1. code is written, has a bug
    2. bug is fixed
    3. another part of the code is changed for whatever reason
    4. bug that was previously fixed suddenly is back

    Maybe I’m being too text-book when in practice it means something else. It certainly means something else in other peoples’ minds…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s