The general rule of thumb when porting an open-source package is to keep track of the changes you make to get it to build and execute on your system, and if you think the changes would be useful to the community at large, to submit them to the maintainers of the package. Usually, this also has the benefit of reducing the effort for future ports of the same package.
I have ported many software packages to VOS and OpenVOS, and I usually try to send in my changes to the maintainers. But not always. Here’s why.
1. Some changes are specific to the OpenVOS environment. If I make a change to work around a restriction that only applies to OpenVOS, then there is little point in sending this change upstream. The maintainers will generally reject such patches. An example might be the limit that pre-17.0 versions of OpenVOS put on the lengths of file names.
2. Some changes may have already been adopted in later releases of the open-source package. Before sending in any changes, it is always a good idea to check and see whether someone has beaten you to the change. This is especially true if it has been a while since you downloaded the original source code. There is no point in wasting everybody’s time with stale changes.
3. The changes are actually in a different product. For example, I recently finished porting MySQL 5.1.48 to OpenVOS Release 17.1. I was able to get it to use the new dynamic linking facility on OpenVOS 17.1 by making various changes to the build scripts. But there is no point to sending these changes to the MySQL team, because the changes are actually in the autoconf package, which is maintained by a different team. The MySQL package is just a user of autoconf; they don’t have any control over what it does for any given platform.
4. Too much time has passed between when I grabbed a copy of the package and today. The problem here is that an open-source package is a moving target. While some packages are quite stable and are infrequently updated, others are undergoing constant change. I spent 9 months porting MySQL 5.1.48, because it was a part-time effort, and because even once it was ported, I had to sync up with our internal test and release process. So by the time I was ready to send some patches back to the MySQL team, they had moved up to version 5.5 (in the generally-available cycle) and version 5.6 (in the development cycle). Many of the changes that I had to make no longer apply cleanly; in some cases, the source files have been renamed or moved to new directories. I could do the work to completely update the patches to the current version, but that’s a lot of work, and, at least in my view, not worth the effort it would require. The lesson for me is that I should have been sending the changes upstream as soon as they were stable in my version. That’s obviously something of a judgement call.
Sometimes, you can take all the right steps to send in a specific, well-written, well-debugged patch, and the maintainers will still ignore it or reject it. That can be frustrating, but don’t get worked-up over it. Many open-source packages are maintained by volunteers, and so they have limited time to deal with patches for uncommon platforms.
In the case of the OpenVOS port of MySQL 5.1.48, I elected to open 5 specific bug reports for well-defined, independent issues in the MySQL package that my research shows are still present in the current development release. I also opened up a bug report so I could contribute back all of our changes; a step that is consistent with the terms of the GNU Public License. In each of these cases, I contributed a source-code patch that shows the changes that I think are appropriate to close out the bug report. I am hopeful that the MySQL team will integrate the 5 specific changes that I requested. They represent issues that could affect other platforms, not just OpenVOS. If you are curious to see the patches I have sent to MySQL, visit http://bugs.mysql.com, click on Advanced Search, and look up bugs 44300, 44832, 60907, 60908, 60910, 60911, 60912, and 60913.
The OpenVOS port of MySQL 5.1.48 will be called “MySQL for OpenVOS, Release 2.0” by Stratus, and it will be generally available soon, concurrently with the availability of OpenVOS Release 17.1.
Company