From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-06-04 15:15:50
>> 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
>> 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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk