Posted on 9 Comments

Bug#27628 revisited. Deliver code, not bureaucracy!

I reported “Processlist shows status NULL when server is purging/managing query cache” in April 2007, while I was still in MySQL support engineering. This issue actually made tracking down other bugs and customer issues take longer. About a year later, MySQL 6.0 codebase apparently has the progress info. By the way, we are essentially talking about a one-line fix, adding something like thd->proc_info=”Flushing table from cache”; at the appropriate spot.

In the mean time, three bugfix meetings have spent time on this item (judging by the tags), those are meetings where MySQL (re-)prioritises some bugs for fixing. That’s an awful lot of time to waste euh spend on this thing. The bug entry itself is still open as “feature request”, and I presume MySQL support and bug engineers are still wasting time due to the insufficient reporting in 5.0 and 5.1. In the latest comment one developer suggests closing it (since it’s in 6.0). But…

Why not just put the one-liner into 5.0 and 5.1 and be done with it? There can’t possibly be any adverse functional impact to this fix. Well not that that’s hindered a meriad of other 5.0 “fixes” from creeping into the world, but this one should really be harmless! And it would actually help users and support engineers. Deliver code already, today!

Posted on 9 Comments

9 thoughts on “Bug#27628 revisited. Deliver code, not bureaucracy!

  1. The underlying problems that made it interesting have been fixed, at least sufficiently well. 5.0 and 5.1 aren’t likely to get any low impact feature requests implemented since both are supposed to be stable now. 6.0 is where they currently go. It’s not taking support and bug engineer time because it’s no longer happening to a significant degree.

  2. Then why discuss this in all those bug meetings, and why is the issue still open as a feature request?

  3. Once to say it was of interest to help track down a problem, once to review and correct missed go ahead and fix this in 6.0 decision. Still open because a development manager hasn’t decided definitively no for 5.1 or 5.0 – you as an end user want it. Dev has asked for that agreement to close.

    If you want to argue that it needs doing in 5.1 or that it’s breaking something in 5.0 so it has to be fixed, now’s the time to do it before the window finally closes on those versions.

  4. I made that argument half a year ago, see the bug comments.

  5. I’d already read the bug report before I replied.

    Have a good trip to the UC!

  6. Then it should be raised again. It is just ridiculous that a very simple patch can’t be authored that would not only help internal Q/A and engineering efforts, but is also beneficial to the wider community. How does it benefit MySQL not to implement such a fix?

    Politics and bureaucracy for their own sake serve no purpose but their own.

  7. It wouldn’t significantly help internal QA and engineering efforts. There’s a patch in the bug that’s been around since July 2007 and has already been added to 6.0. MySQL’s Support team provided it, back when we were still seeing some problems with deleting lots of entries from large query caches. We no longer are because those bugs have been fixed. Maybe Arjen still thinks that this is a hot topic when it no longer is. That isn’t a great reason for making changes to a production release. Unless someone knows of problems in current versions that might make it more significant? Hearing about them would be great if there are any.

    Adding a feature request or any other change to a production or release candidate version carries the risk of introducing a regression bug and breaking something else. Not adding low significance feature requests that don’t affect many people to a production release benefits everyone who is using MySQL and doesn’t want unexpected breakage of production systems. It’s be nice if developers were perfect and never introduced bugs with changes but that’s not the real world and we’ve seen too many cases where bug fixes introduced new bugs.

    MySQL is becoming a lot more serious about not breaking things for production users, after seeing far too many cases where changes did that. Being a bit more sensible about what should be added to production releases is one symptom of this belated recognition that even simple changes are a risk.

    If there was something that caused this to affect a significant number of people it might be worth taking that risk. Which is why I invited Arjen – and you – to write more if you think it is still affecting lots of people.

    For background on how MySQL is becoming a bit more sensible about what it adds and when, see Kaj: Release Criteria: Aligning official documentation with reality and the related blog posts and documentation about bug triage and release criteria. You might also find How MySQL Treats Security Vulnerabilities interesting.

    Being more serious about not breaking things has worked. Still more to do with improving testing by developers and QA but the improvement is clear.

    It’s not fun to deliberately not add something because you don’t think it’s worth taking the risk for a feature request but that’s what it takes to improve life for people using MySQL in production. At times it’s very frustrating… but we do have an obligation to people who don’t want us breaking their production systems.

    This is also why we tell MySQL Enterprise customers to use quarterly service packs unless they need a bug fix that’s only in a monthly rapid update. The QSP is usually a three month old version with only fixes for regression bugs and critical other bug fixes added. The same fewer changes, so fewer chances for unexpected breakage due to regression bugs reasoning.

  8. I understand the need to balance feature requests with the risk of regressions. IMHO this highlights another example of why the Enterprise model is broken. The changes should be able to be pushed into community for testing by the general population before being pushed into Enterprise. Regardless, that is a whole different discussion.

  9. Yes, you definitely have a point about the MRUs going to community users. That’s clearly a case where the revenue model is driving releases. That’s interesting because if it makes money it pays the bills for more developers to fix bugs but there’s some quality cost for it. Trying harder to cut down on the number of regression bugs is one way of dealing with that… we’ll see how it works – too early to know right now. It definitely wasn’t working well enough before the new bug triage system and more focus on deciding what not to put in.

    The other side of the make money deal, more developers to fix bugs, is also happening and now there are many more dedicated to that than before. Also more people doing QA. And still hiring more as well.

    One idea that did receive a favorable response was aligning the Community releases with the MRU that is expected to be the base for the next QSP. That way the QSP will get the benefits of up to three months or so of Community use of the MRU. It’s not possible to see this right now because no new QSPs were released for a while and then a security bug prompted an urgent release for both Enterprise and Community.

    Since I work for MySQL/Sun I can’t knock paying the bills too much – Enterprise customers end up paying for my salary. It’s necessary, just a case of finding the best mixture. Nobody ends up 100% satisfied but hopefully it doesn’t work too badly. Lots of differing opinions about that. 🙂 But I am pleased to see more develpers dedicated to bugs and more QA, so there’s reason to hope that the community is getting that payback.

Comments are closed.