Subject: Re: [boost] [Git] Moving beyond arm waving?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2011-02-07 21:30:54
On 2/7/2011 7:57 PM, Dave Abrahams wrote:
> At Mon, 07 Feb 2011 09:53:52 -0600,
> Rene Rivera wrote:
>>> What about a library developer? What does the tree structure they work
>>> with look like? How does integrate with their development repo? I
>>> guess the non-version controlled tree produced by the above could be
>>> used as a "complete (integrated) release tree", but I'd like to know
>>> the specifics, and give them a try.
>> I would also like to know:
>> 1. How does that non-versioned complete integrated tree work as regards to
> Today, you call GenHeaders explicitly, but if you check out Marcus' work you
> don't have to.
I tried finding where & how Marcus did what you say, by going to the
github link you give in the other response.. But I don't see what there
you are referring to.
>> 2. What does it mean for testing? Specifically, complete incremental testing?
> Nothing? What, specifically, are you worried about?
OK.. How would we run the existing testing in incremental mode with a
"forwarding headers tree plus separate sources"? What would testers need
to rely on? Cmake? Python? Ryppl? Ctest? SSH? Git? FTP? HTTP? HTTPS? Git
>> 3. Or is there no way to get a complete with source integrated tree?
> Please define "complete with source integrated tree" so I can answer that
I mean a tree in the form we have it now, or equivalent to what we
intend to *release* as the *single* Boost C++ Libraries package. I ask
from a testing manager POV. I need to know what the changes might be for
testers and me managing the testing infrastructure. And testers need to
know what will be required of them. I'm not that interested in knowing
what the experience is from the library developer POV, because I know
Beman and others will investigate that aspect more fully than I could.
>> I'm worried as not having an easy way to get that would make testing rather
>> Note, I dont' consider "use ryppl", or "use cmake", as an acceptable answer
>> ;-) As being locked into any particular tool is something I'm vehemently
> I don't think I'd give you an answer like that to any of these questions. But
> that said, being "locked in" somehow is unavoidable; we're locked into SVN now
> aren't we? We're certainly locked into C++ and Python and Boost.Build and
> DocBook and BoostBook and QuickBook and... the list goes on. Or do you mean
> something distinct by "locked in?"
Note, I'm ignoring doc tools with this..
I guess I do mean something distinct by "locked in". The current set of
tools, a good portion of them just scripts, do not in my view lock us in
because they are relatively straightforward to move to something else
that provides the basic equivalent functionality. This is because they
map essentially to operations one could do by hand. But I do concede
that is a rather thin definitional line ;-) My fear is that we end up
with a system that is conceptually hard to understand how to put
together and hence hard to make work. For example, testing at the moment
doesn't depend on SVN. It's possible to download the tree as a tar
archive through the almost universally available HTTP protocol. This is
because we have testers, or at least have had testers, that can't do
anything else. So if there's a requirement to have Git protocol access,
that's likely a killer for testing. This is just one example. I'd have
to see what the entire testing pipeline looks like to figure out where
the "locked in" points are. I.e. I need to know what's actually going
on, rather than just a "run this and that's it" answer.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk