Re: [boost] Boost Development Environment proposal

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

"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message 
news:BAY110-DAV118A20B18F62537D70D809D4210_at_phx.gbl...

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

I don't like this sticker "at any price". It have some negative connotation. 
Otherwise, yes. If I don't care about latest changes.

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

Why more? EXACTLY the same amount. I need to make my changes and I need to 
make sure it works with your changes. I just propose to split this efforts 
in time and do it in two independent steps.

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

How "reasonably sure" I have to be? And how "more careful"? 65% careful? 
With highly portable development, when you library is targeted to work on 30 
different configurations, you can't be sure in anything. Nor you can't be 
careful. The only way to be really sure is *run the test*. To run the test 
you need to commit the 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 
>> (because
>> I went on vacation right in a middle;0)
>
> So what's the hurry to commit your changes then? :)

To test them! ;) I was doing porting, then I went on vacation, then I came 
back and continued.

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

You may be more or less sure that your own test will pass (rather less - 
nothing is sure until code is committed and tested on all platforms). But 
what about 1000 other tests that you never run from different components 
that depend on you?

>>>> What if N libraries merged their changes the same time.
>>>
>>> This is not possible, changes are atomic.
>>
>> Within an our? Some cozy Saturday 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.)

I strongly disagree. This "catch the train" will lead us nowhere. Everyone 
should be doing development at their own pace and I don't have to worry 
about other peoples and their need to run some tests nor they need about 
mine. This decoupling in "the only way" IMO.

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

Why? They shouldn't. Until I am done with my changes.

>> In reliable system no one should.
>
> I don't see how a system with high tolerance to bad commits can produce
> consistently good results.

Easily ;) Do you see any practical problem with approach I promote?

Gennadiy