As a Boost developer, if a dependency takes too much time to stabilize, I sever ties with it and reimplement the parts I need. This is rare since I have low tolerance for dependencies anyway. :-)
What if you depend on serialization or GUI lib or XML parser. It might not be possible to "reimplement" all your dependencies. And this is not a good practive in general IMO. Since you are causing breakage to "single definition rule" on library level.
There are really only two possibilities: 1) fix the GUI lib, or 2) sever ties with it, reimplement the parts you need, and explain in the documentation how a GUI lib can be hooked by the user.
I understand that this mindset may be unusual. Still, I find the idea that the trunk is assumed to be unstable a bit odd. The trunk should be stable and everyone should work to keep it that way.
If trunk is stable, how do I test my development?
If trunk is not stable, what motivation do you have for testing your code?
If I am done with my development when can I put it into "stable" trunk?
As soon as you're reasonably sure that it wont break anything.
What if I break something?
Then you have everyone screaming, and you hope that you can do a quick fix before someone reverts your changes to make the trunk stable again.
What if N libraries merged their changes the same time.
This is not possible, changes are atomic.
How long will it take t osort it out?
It'll certainly take less time to sort out compared to if the trunk is unstable (and everyone is more tolerant to bad commits.) Emil Dotchevski.