What can a Drupal 6 maintainer do, if he would like to gain more confidence that Drupal 6 is indeed fine and ready for a 6.0 stable release? Well, pick a well used site and upgrade. This is what I started to prepare for this Monday night for drupal.hu, the Hungarian Drupal community site. It helped that we readied the Hungarian translation earlier, so that it was complete and ready to import.
First things for upgrades is looking over your modules, and weighting what you need, and writing up a list of what you need to upgrade yourself (ie. your own modules and theme). Thankfully, we depend on a surprisingly small number of contributed modules, and have only a small number of custom developed modules (some glue code for our conferences, our link gallery and a custom native Hungarian captcha as well as an editorial helper module). So I sat down and run a test upgrade of the database with the Drupal 6 code. I only got upgrade errors in the locales_translation table (duplicate key for index), which was easy to ignore, since I imported new translations after the upgrade anyway. So I realized I'd better remove the contents of that table before the upgrade.
I sat down with coder module with which the theme upgrade was 15 minutes and the module upgrades only took 3 hours as well. Then by Monday evening I was running a Drupal 6 version of Drupal.hu on my local machine. True to the goal of the test upgrade, I found a critical bug, which I submitted and got solved the next day. So all looked fine locally, and it was time to bring it to the live site.
I announced timed maintenance on Drupal.hu for today morning and sat down to swap the code, run the update and see what happens. I used the new Reimport translation package feature of Localization client which is great help for upgraders, allowing quick import of translations with a nice progress bar (those installing their first Drupal 6 site have all this built into Drupal, but there is no locale upgrade support in Drupal 6 itself).
All-in-all everything concerning Drupal went nicely. There were a few conflicts with our own Subversion system and the Drupal CVS checkouts as well as Drupal 6 making its settings.php read only while it is in our Subversion repository and needs to be writable for svn to be able to update it, but we were quick to solve these as well.
Now Drupal.hu is publicly running Drupal 6, and I am reporting whatever bugs we found in the code. So far I have found two bugs, one I think is critical (duplicate search index rows attempted to be inserted), the other is less critical but can still fill up the log easily (OpenID module not respecting open basedir). We will see how Drupal 6 performs on the server, and what other bugs we find, if any. This would just strengthen the Drupal 6 release and our confidence that it is ready for your consumption.