From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 20:05:35
"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
news:BAY110-DAV160C3BB33542732B238C65D4210_at_phx.gbl...
>>> 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?
I don't care where. I just need them to be tested. Current systems only
tests HEAD.
> Is there a problem with not committing to HEAD before your changes have
> been
> tested?
Yes. I do not know other way to test my changes.
>>> 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.
How can anyone test against my changes if thay are not commited?
>>> 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.
That's really my problem. If I am doing my own development I don't want to
be bothered with making sure it works with latest commits in other parts of
boost. If I am in maintanence stage, I will always test against latest
version of the dependant components and catch the issues as soon as it
appeared
>>>>>> 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.)
Did you read my post here:
http://article.gmane.org/gmane.comp.lib.boost.devel/158491
In "my world" no migrating occures at all. And there is no HEAD (at least in
global sence)
Gennadiy