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