From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 15:51:18
"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
news:BAY110-DAV9D1AAB78C539607616C5ED4210_at_phx.gbl...
>>> 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.
Gennadiy