Re: [boost] Boost Development Environment proposal

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 14:23:02

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

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

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

>> What directory structure are you talking about?
>
> boost/
>
>  foo/
>  foo.hpp
>
>  bar/
>  bar.hpp
>
> the key point being that a library is not allowed to put anything else in
> boost/.

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.

>>> The dependency management can also be introduced at a later date. It
>>> is not
>>> as fine grained as in your proposal - you can't depend on a specific
>>> version - and this is intentional, to keep things simple.
>>
>> What value does it have then? This is what we got now "informally".
>
> The value of the dependency management is to allow subsets of Boost to be
> tested and released.

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)

>>> This step requires
>>> the test infrastructure to be updated to allow testing a specific
>>> library and only pull a subtree.
>>
>> If there is no way to point to older version of my depenencies, what
>> the poiont of subtree pulling? They all going to be the same.
>
> The point of subtree pulling is to verify that the library can be built
> against its dependencies, not against the full boost/ tree as we currently
> do.

I still don't see the difference. What do you win by pullig npart of the 
tree? Disk space? Every time you put you get the same files. Just different 
subsets.

>>> A release also doesn't require any new tools; it can be done
>>> manually by the
>>> release manager. We may be able to streamline it with tools in the
>>> future, of course.
>>
>> Release still require all libraries to be tested together, right?
>
> 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? What are the problems for you personally if we do this? 
Can you list all?

Gennadiy