Alex headshot

AlBlue’s Blog

Macs, Modularity and More

When is a bug not a bug?

2006 Eclipse

When it's RESOLVE NEVER. At least, that's the discussion point being debated in bug 157642, as kindly brought to my attention by Denis. I'm glad I'm not the only one who feels that way sometimes ...

I also appreciate the humour in the bug report (Denis' suggestion to close it RESOLVE LATER was amusing :-). But the fact that the bug was raised also highlights a frustration behind some of the bug prioritisation. John Arthorne made an excellent point -- that there are simply not enough resources to fix all of the bugs in the OPEN state, let alone RESOLVE LATER -- and let's not forget that this is a dedicate team of developers and support staff who are bringing an excellent product to the market at zero cost to me.

The real reason for bringing this frustration up is twofold; firstly, very often, a RESOLVE LATER bug is just as applicable to a later version of Eclipse as the one that it was raised in. John raised the point that the bugs were re-opened in the past, but it caused a large volume of Buzilla spam. (I actually think that's not a good reason to not do it, though; the Bugzilla spam could be filtered out.) But realistically, sometimes the RESOLVE LATER bugs aren't valid any more because Eclipse has already solved that problem in a different way in a later release.

But secondly, a bug in RESOLVE LATER often just means that there isn't time to squeeze it in to a current release. Why put it in that state (as opposed to just leaving it OPEN)? Well, for one thing, it brushes the bug under the carpet. If we move it into this state, we can show that we've not got as many OPEN bugs, and everyone (except the bug reporter) is happy.

It's really these cases I want to bring to the Eclipse community's attention. Granted, the pace of Eclipse development over the last few years has seen clockwork releases on pretty much exactly the same days (including the re-release of the M5 delivery ... what's up with M5 milestone that causes that each year?) -- and, as much as we'd all like otherwise, there simply isn't time to achieve all of the goals in the Eclipse plan, as well as close current bugs and fix old ones. However, if a bug is still valid -- and people are telling the Eclipse community so by re-reporting it -- then it shouldn't be left in a stagnant state. If a bug is RESOLVE LATER in Eclipse N, and after Eclipse N is released the bug is still present (so someone raises it against Eclipse N+1), I'm all for closing the newer bug as the duplicate. However, the bug that it's a duplicate of should be reopened as part of the duplication process, and the version updated to version N+1. Otherwise, it really is RESOLVE NEVER.

I offer as evidence bug 6038 (a four-digit bug number; wow, that's low!). Raised in 2001, it's as valid now as it was then. It was originally released against Eclipse 1.0. It was updated to 2.0, then deferred (the good old RESOLVE NEVER).

  • Bug 37153: Raised against Eclipse 2.1. Closed duplicate.
  • Bug 38870: Raised against Eclipse 3.0. Closed duplicate.
  • Bug 77139: Raised against Eclipse 3.0. Closed duplicate.
  • Bug 129006: Raised against Eclipse 3.2. Closed duplicate.
  • Bug 158282: Raised against Eclipse 3.3 (by me :-). Closed duplicate.

That's the real beef for me. Different people have been reporting this bug against different versions over the entire lifetime of Eclipse; in all that time, it's been in the RESOLVE LATER state. You can see why I called it RESOLVE NEVER, huh?

Fortunately, the original bug has now been reopened against 3.3. Of course, that's no guarantee that it will get fixed; but things have moved on a lot since the original days. There's a Display view in the debugger; the JDT editor has come on leaps and bounds. Even if it's still ultimately dependent on a file somewhere in the system, it could at least be transparently hidden in a plugin state location and the user need never know. It might turn out that this is something that people can help with; stick a 'helpwanted' tag against it, and someone might even contribute a patch.