Re: [boost] Boost Development Environment proposal

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-06-04 17:26:31

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

It's more, because you had to spend time to make your changes work with the 
old version of the lib, then you need to make it work with the new version.

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

To run the tests on platform X, a tester who can run the tests for you needs 
to get your changes. Are you suggesting that the only way this could happen 
is to commit the changes to HEAD?

The only thing you're accomplishing by committing your changes to HEAD is 
that they get merged with commits other people are making. This is a good 
thing, but it's better to instead sync with everyone else's (stable!) 
changes, and only commit your changes when you are reasonably sure they're 
good.

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

Is there a problem with not committing to HEAD before your changes have been 
tested?

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

In that case, you can't be reasonably sure your changes are stable, and 
therefore you need to wait for them to be tetsed before you commit them.

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

If you could "not worry" about everyone else's changes, I'd agree -- but you 
can't. Sooner or later, you will have to face other developer's commits, and 
you'll have to make your code work with them. I think that the more you 
postpone this, the harder it is to accomplish, and the higher the risk for 
your changes to break HEAD -- in particular if someone else has committed an 
extensive (but bug-free) change.

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

Right, so don't commit your changes until you're done with them.

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

Yes, it makes producing stable releases harder.

In your world, to make a stable release, you start with the current HEAD, 
assume nothing about it, run tests, fix bugs, run tests, etc. until it's 
stable, at which point you release it and start working on migrating bug 
fixes back to HEAD. For the next release, you start with no assumptions, and 
so forth (if I understand you correctly.)

If you start with the assumption that "HEAD should always be stable", you'd 
be making more frequent releases, and everyone would be updating more often 
to stay in sync with the more frequent releases. I think you are afraid that 
the more frequent updates will slow you down, but I think that in the long 
run you're going to save time because you "see" changes that affect your 
work sooner and can deal with them locally without involving anyone else 
(besides testers, obviously you can't run all tests yourself.)

Emil Dotchevski