Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 15:51:18

"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
>>> 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.

or use older version of GUI library that you know works.

>>> 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?

I don't care about trunk in general at all. I don't believe we need a notion
of boost trunk whatsoever. I've got trunk version of my library I need to
test. And my library depends on particular versions (possible truck) of
other components.

>> 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.

How can I be "reasonably sure" (yet another "grey" term) until I run the
tests. And to run the tests I need to commit the changes. This is chicken
and egg problem.

>> 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 I am working on port for new compiler? I don't want anyone to test
agains my trunk version until I am done. And it may take me month (beasue I
went on vacation right in a middle;0)

>> What if N libraries merged their changes the same time.
> This is not possible, changes are atomic.

Within an our? Some cozy satuday evening ....

>> 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.)

*Why* anyone but me should care about my bad commit?

In reliable system no one should.


Boost list run by bdawes at, gregod at, cpdaniel at, john at