What is the problem with "To be fixed later" bug status?

Bug #69842 was actively discussed on Facebook recently. Mostly not it's technical content - people do agree that InnoDB probably needs separate doublewrite buffer(s) for every possible InnoDB page size. It's more about bugs processing approaches, so I have to say something about this.

The story was simple enough. I've mentioned this bug in my previous post and yesterday my dear friend Sinisa added some comments and set status to "To be fixed later". This had made bug reporter (who co-incidentally is a "small data engineer" at Facebook) unhappy, because (let me quote):

"...bugs can still be closed as "to be fixed later", which means even it may affect other users (it affect us, at least), nobody will see that as an open issue MySQL has - especially that some of us would like to be fixed sooner rather than later."

This story had got a happy end actually. James Day stepped in and set status "Verified" for this report as a feature request. But question remains: was setting status to "To be fixed later" a proper action in this case, what does this status mean and does it lead to any problems?

Note in any case that "To be fixed later" status had been used in public bugs database for 8+ years at least (for me it was just always there), this is NOT a recent evil Oracle invention. Let me quote my old post explaining both this and "Won't fix" status (also mentioned in that recent discussion):

• To be fixed later - it means that while the problem exists and verified, there is no way to fix it in current GA or development versions, or fix needs serious changes in software or data format, or serious development efforts and thus requires long term planning. Usually it means "To be fixed never".
• Won't fix - developers just do not want to fix this. This is more a "feature" than a "bug", even if user thinks differently. Users often ask for some things that, while make sense for them and their use case, may be against SQL standard or have acceptable workarounds in frames of current implementation etc.

As for problems, Domas later claimed that "To be fixed later" bugs are not visible in searches later. I'd say it depends on how you search. Click here to get the list of all (234 at the moment of writing) bugs having "To be fixed later" status. The status is "terminating" though, and thus the bug in this status is not visible when you search for "Active" bugs. Just try to search for "truncate" among active bugs using bugs database search, and you will NOT find Bug #68184, while the problem of TRUNCATE being surprisingly slow for InnoDB table when buffer pool is big (while DROP is fixed long time ago) is known and important to solve. On the other hand, simple Google search for site:bugs.mysql.com truncate slow shows this bug to me on the first page of results. Note that by default bugs database does NOT include feature requests (S4 bugs) into the search, so current status of bug report from Facebook may be not much better for searches actually.

So, depending on the way you search, having bug with status "To be fixed later" may be a problem (but only if you are not experienced in MySQL bugs search). Any other problems? One is mentioned in my quote above: I made a statement that "To be fixed later" used to mean "To be fixed never". Is this a true statement or a bad joke? Both, to some extent.

Let me explain this. Ideally status "To be fixed later" should be set (for a bug report or feature request that was originally "Verified"!) by a development manager or key developer (like Marko in case of InnoDB) who checked all planned bug fixes for current GA versions, all planned bug fixes and new features for the version currently in development and, based on available resources and priorities, made a decision (as this is his job) to NOT include the fix in any version that is currently under development. Ideally, at the same time, worklog is to be created for this feature and made public, so that people can contribute with ideas, questions and express their need for this new feature (or bug fix).

So, can we even suspect anything as ideal as above in case of bug #69842? Obviously we can not. Even if we assume that Sinisa has the power of making decisions on further InnoDB development, hardy he spent enough time on Monday to make sure this does NOT fit into InnoDB plans for MySQL 5.7 (that is still at very early stage of development. He had not referenced any worklog created (and this is not so easy if at all possible in Oracle it seems to create new public worklogs). Surely bug reporter have some reasons to think that in this case "To be fixed later" may be equal to "To be fixed never"... I may be wrong here, but then I am sure somebody will explain this in public and give some insights on the huge amount of work entire MySQL organization in Oracle did before he sent his comments :)

Another potential problem with "To be fixed later" bugs, even if they had got this status with good reasons and after following the ideal procedure described above, is the following: who and when reviews bugs in these status again? They should be reviewed at least when development of new version starts, that is, recently when work started on 5.7 all old "To be fixed later" bugs had to be reviewed and some of them had to get some comments and status "Verified" back, if they are now considered for a new feature, or status "To be fixed later" re-established for 2 more years (assuming new GA release every 2 years based on recent Oracle habits and statements). Please, check the list of "To be fixed later" bugs and try to find any evidence of something like this happened any time since 2011.

I know for sure only one iteration like this happened, and I made it myself back in 2007 or so maybe, probably even before MySQL AB joined Sun (some time before 5.1 GA). I worked with Trudy (and maybe Peter G.), main MySQL architects of that times, and was able to re-open some of "To be fixed later" bugs, not many. I am not sure if anybody tried to repeat this again, especially recently in Oracle. Let me stay corrected...