Re: [boost] Boost Development Environment proposal

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 15:25:37

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:018901c7a6d9$6d1e8820$6407a80a_at_pdimov2...
> Gennadiy Rozental wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>> news:016b01c7a6d2$7722c9a0$6407a80a_at_pdimov2...
>>> Gennadiy Rozental wrote:
>>>> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>>>> news:012301c7a6cc$59a39360$6407a80a_at_pdimov2...
>>>
>>>>> My current development model is sync against CVS HEAD, do work,
>>>>> commit, check test results, fix. My use model is sync against CVS
>>>>> HEAD, compile project, yell at whoever introduced a regression in
>>>>> the boost component I'm
>>>>> using. This works well for me and I'd like to keep working in a
>>>>> similar way.
>>>>
>>>> IMO this is not the desirable scheme in general. Actually this is
>>>> exactly what we *should not* be doing IMO.
>>>
>>> It works for me.
>>>
>>> As a Boost user, I simply don't use Boost components whose HEAD
>>> versions are
>>> unstable.
>>
>> An "average" Boost user is primarily interrested in latest released
>> version.
>
> Almost; the user is typically interested in a version that works and
> contains the libraries s/he needs. A suitable release may not exist (yet).

This is the way things are now. In a future we hopefully make boost releases 
more frequent and users don't have to go into undesirable territory of 
unreleases libraries.

>>> 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.
>
> In this case I'll fix these libraries myself.

Well, you maybe the one who can easily fix any boost library one uses. An 
"average" boost developer (me including) can't in general. There is also a 
huge problem with two developers making independent changes to the same 
component.

>> And this is not a
>> good practive in general IMO. Since you are causing breakage to
>> "single definition rule" on library level.
>
> There is no observable downside to this conceptual breakage, whereas the
> breakage resulting from a failed dependency is quite visible.

There are quite observable downsides:

* You may cause ODR violation to anyone who is using both yours and 
dependant library.
* Your code most probably is not tested
* You are requires to maintain this code now, inncluding porting on new 
compilers.
* Users might be confised. The see class Foo used in your code. They expect 
it to be from library libFoo. But thre libFoo docs mention different 
interfaces. libFoo developer now have t ofigure out where this discrepency 
comes from.

and so on.

>>> 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?
>
> You make an incremental change, test it locally, then commit to trunk?

I don't care about local testing for this discussion. I do my testing on one 
compiler I have access to. Now I need to test agains 30 other 
configurations. It may take me month or two to clear up all the problems.

> I didn't mean "stable" as in "guaranteed to pass all tests", more like as
> "stable enough for practical use".

This is one of those "grey" terms I believe we have to avoid as a plague. 
Every one have different understanding what "stable enough" means. We need 
formal definitions that do not leave a space for doubt. Last release version 
of boost is stable. No one ever going to make any changes to it to disrupt 
my testing. And until I am realy to test against new version of dependancies 
I would stick with it. Then I can add them one by one.

>> If I am done with my
>> development when can I put it into "stable" trunk? What if I break
>> something? What if N libraries merged their changes the same time.
>> How long will it take t osort it out?
>
> Large commits are always a problem. My suggestion is that we should simply
> avoid large commits. If the incremental steps towards the goal are visible

How do you invision this to happend ;)) With 100+ developers working 
simultaniously around the world. Will I have to get a ticket to commit my 
changes?

> in the trunk, they can be tested and the problems can be fixed as they
> appear, rather than as one large batch at the end of the day.
>
>> That's good goal. I support it. But this tree could exist as a
>> reflection of actual tree (using svn externals):
>> boost/
>> foo/       -> foo/truck/boost/foo
>> foo.hpp -> foo/truck/boost/foo.hpp
>>
>> bar/       -> foo/truck/boost/bar
>> bar.hpp -> foo/truck/boost/bar.hpp
>>
>> How run svn update in this directory and you pull all you need.
>
> As I understand it there are technical problems with svn:externals that 
> make
> the above not work as well as it could. But it's possible.

The problem is technical, meaning it should be easiest for us to fix ;)

>> How can I release and test my subset if I can't compile with truck
>> version of library I depend on. I don't really care about latest changes?
>> I
>> would be happy to work with last stable version (last boost release)
>
> You can compose a release by using a specific library version. It should 
> be
> possible to use the version from the last release as a starting point.

I can compose whatever I wont. How will I test it?

>> I still don't see the difference. What do you win by pullig npart of
>> the tree?
>
> Test failures if a library #includes "boost/foo/something.hpp" without foo
> being listed as a dependency. Without this check, dependencies tend to 
> find
> their way into your library while you're asleep. :-)

This is achieved in my solution diferrent (easier IMO) way. If library A is 
missing from library B dependency list, the A/<version>/boost is not added 
to the list of includes and B fails to compile. This is the safest possible 
solution, don't you think?

>>> Right. The release process basically consists of integration testing.
>>
>> And this is what we should be avoiding. There should not be testing
>> stage during release.
>>
>> Let's take a look on this from different prospective: what in my
>> proposal you find incorrect?
>
> I see nothing incorrect per se in your proposal; it's quite good. But how 
> do
> we get there from here? How many extra tools do we need? Can we implement 
> it
> in small steps?

I don't believe we need any extra tools. We potencionally need to make a 
change in make system to support explicit dependency specification. And we 
need to change release packaging script to select components that are ready 
for release. For example, in comparison with Beman proposal it doesn't 
require any scripts/human efforts to maintain stable branch.