Re: [jamboost] Re: bjam --version

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-28 05:08:21

Victor A. Wagner, Jr. wrote:
> When I first saw the suggestion that I got a tarball, I wrote a very
> snappy, angry, and not very humorous piece about not being a eunuch (a
> name I decided to apply to a *nix user, it being what appears to be an
> acceptable spelling of the singular of unix (at least if you pronounce it
> in American English, my milk tongue)).
> I have NO idea what a tarball is, other than *NIX people seem to go gaga
> over them.

I apologise for confusion, but "tarball" as I use it, means "the big file 
which you download to install something". I'm not aware about any
other word with the same meaning. 

Besides, not being an american, I have no idea what "go gaga" means, not to 
mention that I have some doubts as to whether calling Unix users eunuchs is 
polite or not.

> I don't know if I have any tools that would reliably deal with one, and I
> don't really have time to find out.
> The almost implicit assumption that if you're a "real programmer" you've
> got to understand all this gobbledegook from the *nix world simply isn't
> true. I've GOT CVS, and I use it, THAT is a tool that we all have (or
> could trivially) and it's _supposed_ to be the "official repository" of the
> boost library.
> You're right. I'm building directly from the CVS output (as noted in
> another reply) once or twice a day.

But you yourself said that you've downloaded m6 zip! That one is entirely 
self-contained and testable outside of Boost. If you prefer to test out of 
CVS, you don't need to download anything.

> what follows is OPINION
>
> IF you want people to check the ongoing work, it behooves the "library"
> developers to make it as simple as possible for us to get (and test) the

"us" = library users?

> work. This means that the users should NOT have to change ANYTHING in their
> testing procedure that has to do with imminent releases or any other
> entirely internal (to the library (boost in this case)) conditions. 

I see what you mean, but how is this related to Boost.Build?

> it is
> unacceptable that a tester may suddenly need to update -r
> SOME_MAGIC_LABEL because a release branch has taken place. the main
> reason is that "SOME_MAGIC_LABEL" has no meaning to the testers
> they might have missed the "we're gonna release 1.30.2 next week" message
> on the EMail.

Again, I see no relation to Boost.Build. We only make tags, not branches so 
far, and it's quite possible to use CVS HEAD. 

<offtopic>
I also disagree to you. Branches are necessary in some circumstances, and 
Boost releases is one such circumstance. If you prefer to use HEAD, that's 
fine. If you'd like to stick with released version, you have to test release 
canditate. The choice is yours.
</offtopic>

> I really don't see any other reasonable approach to dealing with a large
> project that (in some cases) needs to be tested all together. If there is
> no "anchor" for what to test, then how does one automate the testing?

Seems like we're gone very far offtopic.

- Volodya