[1.36.0] Getting Started changes (ticket #1744 plus other fixes)
Before we can ship 1.36.0, some "Getting Started" documentation changes are needed. These changes are the only thing preventing 1.36 from shipping. Enough said. * Section 1, Get Boost, both Windows and Unix Variants: need to begin with a suggestion that users first check for the availability of platform specific installers, linked to the correct URL. [Rationale: the platform specific installers are the preferred way for users to install Boost if their platform is one of those supported.] Questions for Doug: Are the platform specific installers to be hosted on SourceForge as part of the "boost" package? What is the initial set of platform specific installers that will be provided for 1.36? * Section 1, Get Boost, Windows: current text needs to be updated if Boost Consulting is not going to be also providing installers. [Rationale: The current wording is very specific, thus needs careful adjustment to match reality.] * New section, before the current section 1: Suggest visiting http://www.boost.org/doc/libs/1_35_0/more/getting_started/index.html to see if there has been a "Getting Started" documentation update. [Rationale: that way we can push out better docs as soon as available, instead of having to wait for the next release.] * Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default. [Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented, and (3) it needs to be crystal clear how to build the full set.] * Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after the current contents, needs to give the exact command line for building all library variants. [Rationale: resolves (3) in prior item.] Since Dave is on vacation, I'm not sure he will be able to make these changes. If he can't make them, I'll give it a try. Thanks, --Beman
on Sat Aug 09 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Before we can ship 1.36.0, some "Getting Started" documentation changes are needed. These changes are the only thing preventing 1.36 from shipping. Enough said.
I'm very glad to make the changes provided we can figure out what they are. That is something I've been with concerned with for weeks.
* Section 1, Get Boost, both Windows and Unix Variants: need to begin with a suggestion that users first check for the availability of platform specific installers, linked to the correct URL.
[Rationale: the platform specific installers are the preferred way for users to install Boost if their platform is one of those supported.]
Questions for Doug: Are the platform specific installers to be hosted on SourceForge as part of the "boost" package? What is the initial set of platform specific installers that will be provided for 1.36?
Waiting for someone to tell me what the URLs are.
* Section 1, Get Boost, Windows: current text needs to be updated if Boost Consulting
ahem. Boostpro Computing :)
is not going to be also providing installers.
[Rationale: The current wording is very specific, thus needs careful adjustment to match reality.]
We probably will continue to provide free installers, but they may be the same as the Boost ones. In that case, it doesn't make much sense to point people at Boostpro in the Boost documentation.
* New section, before the current section 1: Suggest visiting http://www.boost.org/doc/libs/1_35_0/more/getting_started/index.html to see if there has been a "Getting Started" documentation update.
Good idea. We should make the URL shorter though ;-)
[Rationale: that way we can push out better docs as soon as available, instead of having to wait for the next release.]
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default.
[Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented,
I'm not so sure. While they may have other benefits, the new defaults are going to make the getting started instructions more complicated.
and (3) it needs to be crystal clear how to build the full set.]
Yeah, but that's not nearly enough. We also need to make sure that the instructions for building the examples in the getting started guide are all correct, including all their command-line variations, for all platforms, and don't leave out "silly" details like the potential need to set LD_LIBRARY_PATH (or whatever other platform-specific environment variable may be required) now that we are no longer building static libraries by default. Testing these instructions for all platforms is a large job, and I'm not in a position to do it by myself. In case anyone's wondering why I didn't "simply" go ahead and update the GSG when I discovered that the default build choices had broken it, that's why.
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after the current contents, needs to give the exact command line for building all library variants.
[Rationale: resolves (3) in prior item.]
Since Dave is on vacation, I'm not sure he will be able to make these changes. If he can't make them, I'll give it a try.
I'm somewhat available, but like I said, the changes to the defaults have made things a lot more problematic than they used to be, so we'll need to get lots of people to put attention on this. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sat Aug 09 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Before we can ship 1.36.0, some "Getting Started" documentation changes are needed. These changes are the only thing preventing 1.36 from shipping. Enough said.
I'm very glad to make the changes provided we can figure out what they are. That is something I've been with concerned with for weeks.
I've finally gotten rst2html.py working on my machine; bjam was looking for it a directory different from where the docutils download puts it. I tested by generating the current trunk more/getting_started, and identical html files were produced. Thus it seems to be working OK. Thus I can make minor updates without bother you. I've committed changes to index.rst and unix-variants.rst, and will do windows.rst as soon as testing is complete. I couldn't figure out how substitution works, so I hard-wired the version number on line 23 of index.rst. If you could fix that I would appreciate it.
* Section 1, Get Boost, both Windows and Unix Variants: need to begin with a suggestion that users first check for the availability of platform specific installers, linked to the correct URL.
[Rationale: the platform specific installers are the preferred way for users to install Boost if their platform is one of those supported.]
Questions for Doug: Are the platform specific installers to be hosted on SourceForge as part of the "boost" package? What is the initial set of platform specific installers that will be provided for 1.36?
Waiting for someone to tell me what the URLs are.
I haven't heard from Doug, and in any case I am leery of putting in anything specific until the real files are available at the final location.
* Section 1, Get Boost, Windows: current text needs to be updated if Boost Consulting
ahem. Boostpro Computing :)
Oops! Sorry.
is not going to be also providing installers.
[Rationale: The current wording is very specific, thus needs careful adjustment to match reality.]
We probably will continue to provide free installers, but they may be the same as the Boost ones. In that case, it doesn't make much sense to point people at Boostpro in the Boost documentation.
* New section, before the current section 1: Suggest visiting http://www.boost.org/doc/libs/1_35_0/more/getting_started/index.html to see if there has been a "Getting Started" documentation update.
Good idea. We should make the URL shorter though ;-)
See my draft wording in trunk/more/getting_started/index.html.
[Rationale: that way we can push out better docs as soon as available, instead of having to wait for the next release.]
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default.
[Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented,
I'm not so sure. While they may have other benefits, the new defaults are going to make the getting started instructions more complicated.
For unix-variants, I added instructions for building all variants, in addition to the defaults. That did add a bit more wording, but not enough to be worrisome IMO.
and (3) it needs to be crystal clear how to build the full set.]
Yeah, but that's not nearly enough. We also need to make sure that the instructions for building the examples in the getting started guide are all correct, including all their command-line variations, for all platforms, and don't leave out "silly" details like the potential need to set LD_LIBRARY_PATH (or whatever other platform-specific environment variable may be required) now that we are no longer building static libraries by default. Testing these instructions for all platforms is a large job, and I'm not in a position to do it by myself.
I've tested the two unix-variants build examples on Linux. I'm now starting to do similar tests on Windows. That's not as good as testing all combinations, but at least we know the given examples do in fact work.
In case anyone's wondering why I didn't "simply" go ahead and update the GSG when I discovered that the default build choices had broken it, that's why.
Understood.
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after the current contents, needs to give the exact command line for building all library variants.
[Rationale: resolves (3) in prior item.]
Since Dave is on vacation, I'm not sure he will be able to make these changes. If he can't make them, I'll give it a try.
I'm somewhat available, but like I said, the changes to the defaults have made things a lot more problematic than they used to be, so we'll need to get lots of people to put attention on this.
Yes. I hope others will read "Getting Started", and actually try the instructions on their systems ASAP. --Beman
on Mon Aug 11 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
on Sat Aug 09 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Before we can ship 1.36.0, some "Getting Started" documentation changes are needed. These changes are the only thing preventing 1.36 from shipping. Enough said.
I'm very glad to make the changes provided we can figure out what they are. That is something I've been with concerned with for weeks.
I've finally gotten rst2html.py working on my machine; bjam was looking for it a directory different from where the docutils download puts it.
Yeah, my fault. docutils.jam was hacked together for my standard usage scenario (working from a development snapshot). I'd say open a ticket for that, but I'm hoping we'll retire docutils.jam soon ;-)
I tested by generating the current trunk more/getting_started, and identical html files were produced. Thus it seems to be working OK.
Thus I can make minor updates without bother you.
I've committed changes to index.rst and unix-variants.rst, and will do windows.rst as soon as testing is complete.
I couldn't figure out how substitution works, so I hard-wired the version number on line 23 of index.rst. If you could fix that I would appreciate it.
I don't think you can do any better than making a named link in release_variables.rst that gets updated for each release. ReST is pretty limited in some ways and the GSG stretches its inherent programmability just about to the limit. I get the impression that quickbook templates are more flexible and powerful. I'd like to collaborate with a quickbook expert on a conversion. All that said, the link probably shouldn't go in index.rst, since that file has little content that's likely to change and people are likely to link to the windows/unix-specific files. Based on that information, if you still want me to try to make the change, please let me know.
* Section 1, Get Boost, Windows: current text needs to be updated if Boost Consulting
ahem. Boostpro Computing :)
Oops! Sorry.
is not going to be also providing installers.
[Rationale: The current wording is very specific, thus needs careful adjustment to match reality.]
We probably will continue to provide free installers, but they may be the same as the Boost ones. In that case, it doesn't make much sense to point people at Boostpro in the Boost documentation.
We will probably start selling binary installers for platforms that Boost isn't directly supporting, so it might not hurt to mention that.
* New section, before the current section 1: Suggest visiting http://www.boost.org/doc/libs/1_35_0/more/getting_started/index.html to see if there has been a "Getting Started" documentation update.
Good idea. We should make the URL shorter though ;-)
See my draft wording in trunk/more/getting_started/index.html.
Looks fine. As a stylistic matter, it would probably be better to use an anonymous hyperlink ("__"), rather than such a long name. So that it makes sense when you put the link in release_variables.rst, you can name the link this way: The `Boost website version of this Getting Started guide`__ blah, blah... __ LatestGSG_ and then use .. _LatestGSG: http://www.boost.org/doc/libs/1_36_0/more/getting_started/index.html in release_variables.rst
[Rationale: that way we can push out better docs as soon as available, instead of having to wait for the next release.]
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default.
[Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented,
I'm not so sure. While they may have other benefits, the new defaults are going to make the getting started instructions more complicated.
For unix-variants, I added instructions for building all variants, in addition to the defaults. That did add a bit more wording, but not enough to be worrisome IMO.
Yeah, but I bet your instructions don't work for MacOS or AIX (which use different symbols for the library path), or even on Linux if you're a user who doesn't have write permission on /usr and has to use --prefix= to install elsewhere (since you didn't mention LD_LIBRARY_PATH in your instructions). That's where at least some of the complication is going to come from. Honestly, I don't understand why we don't just expand the installed defaults to include static libraries so the existing instructions work. If you're worried about destabilizing the release because static libraries don't build successfully somewhere, I have to ask you: would it really be acceptable to release Boost like that in the first place? I worked *extremely* hard to make sure that the instructions as they now stand will *not* cause people to run into stupid issues that prevent them from getting started with Boost or decide that Boost is hard to use, and it's very frustrating to see the potential problems taken so lightly. I don't think adjusting the guide to use dynamic libraries is something you can do at the last minute and not cause problems for our users.
and (3) it needs to be crystal clear how to build the full set.]
Yeah, but that's not nearly enough. We also need to make sure that the instructions for building the examples in the getting started guide are all correct, including all their command-line variations, for all platforms, and don't leave out "silly" details like the potential need to set LD_LIBRARY_PATH (or whatever other platform-specific environment variable may be required) now that we are no longer building static libraries by default. Testing these instructions for all platforms is a large job, and I'm not in a position to do it by myself.
I've tested the two unix-variants build examples on Linux. I'm now starting to do similar tests on Windows. That's not as good as testing all combinations, but at least we know the given examples do in fact work.
In certain environments on certain platforms. Er, one environment on one platform.
In case anyone's wondering why I didn't "simply" go ahead and update the GSG when I discovered that the default build choices had broken it, that's why.
Understood.
No offense intended, but I'm not so sure.
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after the current contents, needs to give the exact command line for building all library variants.
[Rationale: resolves (3) in prior item.]
Since Dave is on vacation, I'm not sure he will be able to make these changes. If he can't make them, I'll give it a try. I'm somewhat available, but like I said, the changes to the defaults have made things a lot more problematic than they used to be, so we'll need to get lots of people to put attention on this.
Yes. I hope others will read "Getting Started", and actually try the instructions on their systems ASAP.
I think if you want to have confidence about the result, you'll need to be a lot more aggressive about looking for pitfalls than you have been so far. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default.
[Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented, I'm not so sure. While they may have other benefits, the new defaults are going to make the getting started instructions more complicated. For unix-variants, I added instructions for building all variants, in addition to the defaults. That did add a bit more wording, but not enough to be worrisome IMO.
Yeah, but I bet your instructions don't work for MacOS or AIX (which use different symbols for the library path), or even on Linux if you're a user who doesn't have write permission on /usr and has to use --prefix= to install elsewhere (since you didn't mention LD_LIBRARY_PATH in your instructions). That's where at least some of the complication is going to come from.
AFAIK, I don't have write permission for /usr. Where does /usr enter into the current instructions?
Honestly, I don't understand why we don't just expand the installed defaults to include static libraries so the existing instructions work.
In my tests on both Windows and Linux, static libraries were built, although perhaps not the set some users expect.
If you're worried about destabilizing the release because static libraries don't build successfully somewhere, I have to ask you: would it really be acceptable to release Boost like that in the first place?
It is coming up on two weeks past the target release date. I assume those who want more than the default will simply do a "complete" build.
I worked *extremely* hard to make sure that the instructions as they now stand will *not* cause people to run into stupid issues that prevent them from getting started with Boost or decide that Boost is hard to use, and it's very frustrating to see the potential problems taken so lightly.
I agree. This was the straw that broke the camel's back as far as I'm concerned. I've lost all interest in supporting the current Boost.Build system and look forward to moving one hundred percent to something better, more responsive to user needs, and less likely to break the release process at unexpected moments.
I don't think adjusting the guide to use dynamic libraries is something you can do at the last minute and not cause problems for our users.
and (3) it needs to be crystal clear how to build the full set.] Yeah, but that's not nearly enough. We also need to make sure that the instructions for building the examples in the getting started guide are all correct, including all their command-line variations, for all platforms, and don't leave out "silly" details like the potential need to set LD_LIBRARY_PATH (or whatever other platform-specific environment variable may be required) now that we are no longer building static libraries by default. Testing these instructions for all platforms is a large job, and I'm not in a position to do it by myself. I've tested the two unix-variants build examples on Linux. I'm now starting to do similar tests on Windows. That's not as good as testing all combinations, but at least we know the given examples do in fact work.
In certain environments on certain platforms. Er, one environment on one platform.
In case anyone's wondering why I didn't "simply" go ahead and update the GSG when I discovered that the default build choices had broken it, that's why. Understood.
No offense intended, but I'm not so sure.
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after the current contents, needs to give the exact command line for building all library variants.
[Rationale: resolves (3) in prior item.]
Since Dave is on vacation, I'm not sure he will be able to make these changes. If he can't make them, I'll give it a try. I'm somewhat available, but like I said, the changes to the defaults have made things a lot more problematic than they used to be, so we'll need to get lots of people to put attention on this. Yes. I hope others will read "Getting Started", and actually try the instructions on their systems ASAP.
I think if you want to have confidence about the result, you'll need to be a lot more aggressive about looking for pitfalls than you have been so far.
Sorry, we are out of time. It is as simple as that. Anyone concerned that this will cause a release to be shipped that isn't good enough should start spending more time *early* in the release process looking for gremlins. --Beman
on Mon Aug 11 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
* Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default.
[Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented, I'm not so sure. While they may have other benefits, the new defaults are going to make the getting started instructions more complicated. For unix-variants, I added instructions for building all variants, in addition to the defaults. That did add a bit more wording, but not enough to be worrisome IMO.
Yeah, but I bet your instructions don't work for MacOS or AIX (which use different symbols for the library path), or even on Linux if you're a user who doesn't have write permission on /usr and has to use --prefix= to install elsewhere (since you didn't mention LD_LIBRARY_PATH in your instructions). That's where at least some of the complication is going to come from.
AFAIK, I don't have write permission for /usr. Where does /usr enter into the current instructions?
If you use "./configure; make; make install" as the instructions suggest, the libraries will get installed into /usr/local/lib, which is in the default dynamic library search path on many systems. People who don't have write permission on these directories need to use ./configure --prefix=/some/writable/directory, and that directory is typically not in the default dynamic library search path... which won't matter if you are linking with static libraries. But given the instructions, it will show up with dynamic libraries when you try to run your program. That's one reason the instructions used static libs.
Honestly, I don't understand why we don't just expand the installed defaults to include static libraries so the existing instructions work.
In my tests on both Windows and Linux, static libraries were built,
That's not what http://svn.boost.org/trac/boost/ticket/1744 indicates would happen. Did someone change the default behavior without updating the ticket? If so, this whole issue might have gone away.
although perhaps not the set some users expect.
If you're worried about destabilizing the release because static libraries don't build successfully somewhere, I have to ask you: would it really be acceptable to release Boost like that in the first place?
It is coming up on two weeks past the target release date. I assume those who want more than the default will simply do a "complete" build.
Beman, that's not the point. Yes, they will, but first they'll have to discover that the reason their "Getting Started" experience has failed due to not having the right libraries available.
I worked *extremely* hard to make sure that the instructions as they now stand will *not* cause people to run into stupid issues that prevent them from getting started with Boost or decide that Boost is hard to use, and it's very frustrating to see the potential problems taken so lightly.
I agree. This was the straw that broke the camel's back as far as I'm concerned. I've lost all interest in supporting the current Boost.Build system and look forward to moving one hundred percent to something better, more responsive to user needs, and less likely to break the release process at unexpected moments.
I'm sorry, but while I agree that switching build systems is probably the best thing for Boost, I don't think what's happening here has anything at all to do with technology. This problem is entirely a human one: someone (or some of us) decided to change which variants of Boost were being installed by default and didn't consider the impact on the GSG. This problem could just as easily have happened with any other build system.
I think if you want to have confidence about the result, you'll need to be a lot more aggressive about looking for pitfalls than you have been so far.
Sorry, we are out of time. It is as simple as that. Anyone concerned that this will cause a release to be shipped that isn't good enough should start spending more time *early* in the release process looking for gremlins.
I'm not sure how to take this. Are you suggesting that I should have spent more time early in the process trying to discover that someone else's changes broke my documentation? In fact, AFAICT the GSG was broken by these changes for 1.35, and I didn't really even understand what was going on for a while. Just look at the initial comments in http://svn.boost.org/trac/boost/ticket/1744. Please, I'm not offended by the idea, but if you think I should be doing something differently to prevent this problem in the future, I would like to know precisely what that is. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Honestly, I don't understand why we don't just expand the installed defaults to include static libraries so the existing instructions work. In my tests on both Windows and Linux, static libraries were built,
That's not what http://svn.boost.org/trac/boost/ticket/1744 indicates would happen. Did someone change the default behavior without updating the ticket? If so, this whole issue might have gone away.
Rene made that change about 6 weeks ago to both trunk and release. See http://svn.boost.org/trac/boost/changeset/46957 I think that makes one of the concerns go away, but your other concerns need to be discussed further. I'll try to get back to them, but it will likely be a day or two, and after 1.36.0 ships. --Beman
on Mon Aug 11 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Rene made that change about 6 weeks ago to both trunk and release. See http://svn.boost.org/trac/boost/changeset/46957
You mean I've been needlessly worrying and nagging everyone about this for the past 6 weeks? Couldn't someone have told me, or marked the ticket closed, or done _something_ to indicate that we weren't going to have the problem with 1.36? What a huge waste of everyone's bandwidth!
I think that makes one of the concerns go away, but your other concerns need to be discussed further. I'll try to get back to them, but it will likely be a day or two, and after 1.36.0 ships.
Thanks; it doesn't bother me much now that I think the instructions are probably okay. That said, I'd still feel best if they got thoroughly tested. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Mon Aug 11 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Rene made that change about 6 weeks ago to both trunk and release. See http://svn.boost.org/trac/boost/changeset/46957
You mean I've been needlessly worrying and nagging everyone about this for the past 6 weeks? Couldn't someone have told me, or marked the ticket closed, or done _something_ to indicate that we weren't going to have the problem with 1.36? What a huge waste of everyone's bandwidth!
Note... I did close the ticket at the time. It was reopened at some point. -- -- 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
Rene Rivera wrote:
David Abrahams wrote:
on Mon Aug 11 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Rene made that change about 6 weeks ago to both trunk and release. See http://svn.boost.org/trac/boost/changeset/46957
You mean I've been needlessly worrying and nagging everyone about this for the past 6 weeks? Couldn't someone have told me, or marked the ticket closed, or done _something_ to indicate that we weren't going to have the problem with 1.36? What a huge waste of everyone's bandwidth!
Note... I did close the ticket at the time. It was reopened at some point.
That would have been me. Note that building static libraries does not fix the issue for msvc users, and the instructions are I believe still wrong: the problem is that for msvc it's not enough to simply have built the static libraries as well: they need to have been built against the correct msvc-runtime-variant as well. So for example, a new user who creates a VC++ project, adds a Boost example program to it, and tries to build... will get linker errors because the debug versions of the Boost libraries haven't been built by default, while the MSVC IDE will be expecting them by default. John.
Beman Dawes wrote:
I worked *extremely* hard to make sure that the instructions as they now stand will *not* cause people to run into stupid issues that prevent them from getting started with Boost or decide that Boost is hard to use, and it's very frustrating to see the potential problems taken so lightly.
I agree. This was the straw that broke the camel's back as far as I'm concerned. I've lost all interest in supporting the current Boost.Build system and look forward to moving one hundred percent to something better, more responsive to user needs, and less likely to break the release process at unexpected moments.
Hmm? The behavior change been discussed happened for 1.35. And if you read the discussion in #1744, I'll be happy to help with whatever behaviour change is desired, as soon as everybody agrees on what behaviour should be (and reading the comments does not leave me with impression that any concrete suggestion was made, by anybody). The problem here, apparently, is in the process, whereby: - The folks who discussed behaviour change for 1.35 did not communicate to Dave that getting-started needs to be adjusted. - Dave did not communicate to you that he considers this issue critical Do we actually have any process whereby issues proposed to be fixed in 1.36.0 are getting reviewed by anybody, or sorted by priority? - Volodya
on Mon Aug 11 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
Beman Dawes wrote:
I worked *extremely* hard to make sure that the instructions as they now stand will *not* cause people to run into stupid issues that prevent them from getting started with Boost or decide that Boost is hard to use, and it's very frustrating to see the potential problems taken so lightly.
I agree. This was the straw that broke the camel's back as far as I'm concerned. I've lost all interest in supporting the current Boost.Build system and look forward to moving one hundred percent to something better, more responsive to user needs, and less likely to break the release process at unexpected moments.
Hmm? The behavior change been discussed happened for 1.35. And if you read the discussion in #1744, I'll be happy to help with whatever behaviour change is desired, as soon as everybody agrees on what behaviour should be (and reading the comments does not leave me with impression that any concrete suggestion was made, by anybody).
Rene made a concrete suggestion in http://svn.boost.org/trac/boost/ticket/1744#comment:15
The problem here, apparently, is in the process, whereby:
- The folks who discussed behaviour change for 1.35 did not communicate to Dave that getting-started needs to be adjusted.
Right.
- Dave did not communicate to you that he considers this issue critical
I'm sorry, yes, I did. At least, I made what I think of as valiant efforts to do so. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Mon Aug 11 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
Beman Dawes wrote:
I worked *extremely* hard to make sure that the instructions as they now stand will *not* cause people to run into stupid issues that prevent them from getting started with Boost or decide that Boost is hard to use, and it's very frustrating to see the potential problems taken so lightly.
I agree. This was the straw that broke the camel's back as far as I'm concerned. I've lost all interest in supporting the current Boost.Build system and look forward to moving one hundred percent to something better, more responsive to user needs, and less likely to break the release process at unexpected moments.
Hmm? The behavior change been discussed happened for 1.35. And if you read the discussion in #1744, I'll be happy to help with whatever behaviour change is desired, as soon as everybody agrees on what behaviour should be (and reading the comments does not leave me with impression that any concrete suggestion was made, by anybody).
Rene made a concrete suggestion in http://svn.boost.org/trac/boost/ticket/1744#comment:15
To which you've agreed, and then, in http://svn.boost.org/trac/boost/ticket/1744#comment:21 some other alternative is proposed, as a better one.
The problem here, apparently, is in the process, whereby:
- The folks who discussed behaviour change for 1.35 did not communicate to Dave that getting-started needs to be adjusted.
Right.
- Dave did not communicate to you that he considers this issue critical
I'm sorry, yes, I did. At least, I made what I think of as valiant efforts to do so.
Apparently, this issue came as surprise to Beman, anyway? - Volodya
Beman Dawes wrote:
Before we can ship 1.36.0, some "Getting Started" documentation changes are needed. These changes are the only thing preventing 1.36 from shipping. Enough said.
* Section 1, Get Boost, both Windows and Unix Variants: need to begin with a suggestion that users first check for the availability of platform specific installers, linked to the correct URL.
[Rationale: the platform specific installers are the preferred way for users to install Boost if their platform is one of those supported.]
Questions for Doug: Are the platform specific installers to be hosted on SourceForge as part of the "boost" package? Sure. What is the initial set of platform specific installers that will be provided for 1.36? These are my initial targets: Visual Studio 2005/Visual C++ 8.0 (32-bit) Visual Studio 2008/Visual C++ 9.0 (32-bit) MacOS X (Universal) - Tiger/monolithic installer MacOS X (Universal) - Leopard installer
- Doug
participants (6)
-
Beman Dawes -
David Abrahams -
Douglas Gregor -
John Maddock -
Rene Rivera -
Vladimir Prus