Re: [boost] Boost Development Environment proposal

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-06-04 16:35:56

----- Original Message ----- 
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, June 04, 2007 12:51 PM
Subject: Re: [boost] Boost Development Environment proposal

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

If your goal is to commit your changes at any price, sure, that's the third 
possibility.

In reality, choosing this third option means you'll be doing more work in 
the long run, because at a later time you still have to switch to the last 
version of the GUI lib, at which point you're presented with 1) and 2) 
again.

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

Even if you can't run all tests by yourself, you can run at least some tests 
to be "reasonably sure".

And if we require that HEAD is stable, this is an additional motivation for 
people to be more careful when committing changes.

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

So what's the hurry to commit your changes then? :)

The more extensive the refactoring you're doing is, the more important it is 
for you to update often, so you don't deviate from everyone else's work too 
much. At some point you are "reasonably sure" that your current version is 
stable enough, and you commit.

>>> What if N libraries merged their changes the same time.
>>
>> This is not possible, changes are atomic.
>
> Within an our? Some cozy satuday evening ....

In my opinion, the only way to deal with rapidly changing code base is to 
sync often. This can only work if you know that HEAD is stable (but of 
course if HEAD is bad, you can always sync to the previous version, or even 
revert the bad commit someone else did.)

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

If your changes are relevant to anything, people will care about your (bad 
or good) commits.

> In reliable system no one should.

I don't see how a system with high tolerance to bad commits can produce 
consistently good results.

Emil Dotchevski