Post
by PurpleGurl » Fri Jun 30, 2017 6:01 am
Branches are what those who want to do their own thing should focus on. And if it fulfills a need that should be filled in trunk, it can be merged. Forks are generally reserved for when there are irreconcilable differences in major things. If you fork over every trivial thing, then that unnecessarily divides the project.
Now, if someone wants to roll out a bunch of enhancements or changes that won't make it into ROS, one way to do that without forking the entire project would be to make an unofficial service pack. Like with the idea I rolled around and probably won't put to use, where I'd want to create files tuned for specific architectures or use certain faster code paths, or even files that require certain hardware, then one way to implement that would be a service pack approach with backups of replaced files, and the option to uninstall the newer files and put the originals back. And the replaced files could be moved to easy to find locations in case one had to manually copy them back (like what if the machine crashes but you replace with hardware that's incompatible with the changes).
Now if you want to bundle with certain replaced files (or an installer to use those instead when appropriate), certain software, certain drivers, themes, etc., then what you'd have would be a distribution. There is no need to do a fork when you can just work on specific parts that are not in the mainstream release that can be tacked on at the end.
Now, for the OP's questions. Distributions are one thing. They change very little if any of the core OS and important files. They are to appeal to a certain user segment. For instance, a gamer's distribution might default to either a "cool" theme, or a minimal one, default to lax security settings, not have as many services enabled (certainly no indexer service), have most logs and performance counters disabled, maybe issue performance commands to the hard drives, etc. And they might throw in some modified drivers for certain devices.
I don't believe distributions would harm the project or compatibility overall. Forks on the other hand are another issue, though even they can sometimes work out for good overall. Let's say that someone decides to rewrite their own memory manager from scratch. Ideally, that could be done as a branch. But let's say they fork it. Then let's suppose it is better than ARM3 and the remnants of the other one. Then that can be merged into mainstream if it truly is better.
Now, if it is a fork because someone wants to use it as a base for their own OS, then that would be of little interest to us. And if the consumer base wants it, then a new platform could emerge. Or, maybe the goal is for a lightweight embedded OS or one that will be used in a high security situation. So yes, they might make it fundamentally incompatible, but they might only need it for specific in-house solutions. Like why not a POS terminal or ATM with forked ROS code on it? They might strip down ROS and remove all but what's essential to run a single, specific application and maybe use their own proprietary, closed-source network stack.
What I said years ago is that forks would likely be less of a problem for us than Linux, assuming the forks are after Windows compatibility. In other words, they follow the same "Bible" (ie., being followers of Windows, etc). It isn't trying to mimic an obsolete mainframe OS that none of the programmers have actually used which was replaced by much better hardware and adding GUI support where it never existed. So there is less room for interpretation when coding a replacement for an active, popular OS.
