There are been many non-quantifiable (but valid) reasons why the bugs database athttp://bugs.mysql.com should remain open and have as many bugs open to the public as possible. However, while researching an article recently I uncovered a simple, concrete reason why the bugs database needs to stay as open as possible:
So we know when to upgrade. Really! I was looking at the CHANGELOG pages for MySQL 5.5 and was trying to figure out which changes were pushed into MySQL 5.5 along with being pushed into MySQL 5.1 and which were unique to MySQL 5.5.
While it is fairly simple to figure out some of that — for instance, all of the patches regarding semisynchronous replication are unique to MySQL 5.5 – it was not clear on most of the fixes, particularly the bug patches. Luckily we have the bugs database so we can double-check this.
Let’s say you work for an organization that is contemplating whether or not to upgrade from MySQL 5.1.50 to MySQL 5.5. Looking at the change logs for MySQL 5.5.0, if you can manage to read the entirety of the page, you’ll see a change that notes:
Appending values to an ENUM or SET definition is a metadata change for which ALTER TABLE need not rebuild the table, but it was being rebuilt anyway. (Bug #45567)
Well, that sounds like a great bugfix – making an ALTER TABLE operation that’s supposed to be online, actually an online change. However, if you look at the bug itself, you will note that it was “Pushed into 5.1.40” also. Thus, already being on MySQL 5.1.50, you already have that change.
Without the bugs database it would be virtually impossible to know this — you’d have to cross-reference the changelogs for all the MySQL 5.1 minor versions, or at least the ones that were being worked on in that timeframe….which might narrow it down to 2 or 3 versions, but it’s still excessive.
And of course as fewer and fewer of the bugs are public, we are left trying to figure out what exactly the description on the CHANGELOG page is, without having the ability to search the bugs database.
So please, keep the bugs database as open as possible.
Not just so we don’t submit duplicates, wasting Oracle engineers’ (and our own) time.
Not just so we can submit patches for fixes.
Not just so we can see that a bug exists or is being worked on.
Not just so we can know what a bugfix really entails.
But also so we can know what bugs actually affect us, and what will actually be fixed on an upgrade from one version to the next.
Interested in working with Sheeri? Schedule a tech call.