Norvald is a mysql developer and contact person for distro packager, and in this role he talks to all kind of different distros. There are also Oracle employees who do package for one distro.
mysql is released as tgz but simultaneously also as distro packages. Also the spec file for Fedora and a debian/rules is delivered by mysql, but the uploading/signing is still done by the distro community. So the mysql-released rpms are just for convenience, but the distro rpm is the main mechanism that it gets to the user.
After a GA release, only some bug fixes are merged (chosen by support, not by developers): no new features, no risky bug fixes. It has continuous testing. One month before the release, no new development is done and everything is focused on QA.
Downstream likes to limit the patches on a released patches even more, i.e. only security fixes. Is this really less risk? Upstream does a huge amount of testing on the release, so if you just take patches instead of the release you don’t get all that testing. It also introduces more strain (work and worries) for the packager and for the mysql developer liaison. Therefore, Ubuntu has introduced the “Micro Release Exception”: if upstream has sufficiently good QA and development processes, then there is no need for the packager to take only minimal patches but they can just take the release.
Bugfixes also come from downstream. mysql encourages packagers to report bugs. Bugs reported by packagers tend to get higher priority, because they affect a lot of users. Also Norvald looks at the patches applied by maintainers, but it is much more difficult to convince developers to take these than if there is an actual bug report. Similar for bug reports that stay in the distro’s BTS.
There’s a mismatch between the hardware architectures support by MySQL and by distros, but on the other hand MySQL supports more OSes. But that means there is untested, unused platform dependent code. So MySQL doesn’t accept patches for such architectures, because they can’t test it. They’re willing to do the actual development work, but it will have to remain distro-maintained patches. It’s different for code that is not portable, though (e.g. assuming char is signed): that will be fixed and stays in MySQL. Still, the goal is to have as little patches as possible still applied by the distro.
MySQL maintains a couple of distro repositories. It contains the latest and greatest release. Since this already contains the packaging code, it can serve as a best practices guideline for the actual package maintainer. It’s also a great way for MySQL developers to learn about the packaging problems that you could encounter. Similar to above, MySQL tries to keep their packaging as close as possible to the distro’s packaging (at the moment it’s mostly MySQL learning from the distro). The distro packaging is integrated in the QA process. This also makes required changes in the packaging immediately obvious, so downstream can be warned.
There are differences between distros that are important for the developers. For instance, on Debian installation is interactive, but on Fedora yum is non-interactive, so the root password is generated automatically on installation. And then, from source it is still different of course.
By talking to the distro maintainers, MySQL sees what is different between them and can realize that it doesn’t need to be different. The differences can be resolved by including the variation in upstream itself.
In this entire process, trust between upstream and downstream is important, because people make mistakes and they shouldn’t be blown out of proportions.