Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk