Things have settled down in the last few years, but remember how bad things were with ALSA due to the kernel portion and userspace portions being maintained and distributed separately?
Ted is right that a lot of it boils down to how good the developers are and how much they work to keep things sane, but ALSA is proof that keeping things separate just because one portion runs in userspace does not eliminate all the problems either.
Posted Nov 10, 2011 7:57 UTC (Thu) by khim (subscriber, #9252)
[Link]
I had similar experience with our Native Client work.
Initially we had one single tree where all components resided: binutils, gcc, newlib and nacl core itself (which plays the role of kernel in the nacl ecosystem). In early days it was not uncommon to see the change which affected all components at once. I fail to even imagine the nightmare of trying to do separate development.
But times are changing: our ABI stopped changing so much over time (we needed to make it secure and it's kinda hard to do if there are daily changes), amount of changes in GNU toolchain was also reduced and now we use scheme with separate repos. We plan to push changes upstream which will make coordinated changes even harder (but will make life of our users easier), but this is Ok now because platfrom have quite stable ABI which will be supported for a long, long time.
I think it's points out to the same thing ALSA shows us: initial development often needs to change ABI (since nobody knows how "sane ABI" should look like), later projects can be separated. The only remaining question is: should the immature projects be kept in kernel for "incubation period" or perhaps they must live in separate repo along with patches to kernel till they "graduate" and will be ready to live as something separate from kernel? ALSA hints that first approach is not always feasible.