Subject: Re: [Boost-docs] svn.boost.org wiki
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-07-15 17:51:36
On 7/15/15 9:14 AM, Stefan Seefeld wrote:
> The content of https://svn.boost.org/trac/boost/ seems rather outdated,
> and it has been confusing me a number of times as it wasn't clear what
> is and what isn't up-to-date.
> * There is an entire section "Quick Access to the Boost Subversion
> Repository". Shouldn't that be removed entirely ?
> * The section "Git and Modular Boost" starts with "Boost is moving...".
> Isn't that conversion complete (and thus, shouldn't the docs state that
> clearly) ?
> * There are other seemingly outdated bits, but there are relatively minor...
Some of us have been trying, (and trying and trying ...) to make
progress on getting the Boost website updated to a better scheme which
federates all the boost on line resources in a more convenient way.
We've got the resources allocated, someone to take responsibility for
it, but ... nothing actually happens. This needs more prodding. So
please post this complaint to both the steering committee and the
> What I was actually trying to figure out is how / where to indicate that
> for Boost.Python I would like issues to be submitted with the respective
> github issue tracker, rather than the old Boost Trac instance.
Another rich and interesting question which I would like to see
explicitly addressed. My view is that one of the aims and benefits of
"Boost Modularization" would be that certain aspects of boost libraries
don't have to be in lockstep any more. There's no reason why every
library has to use trac. I think this should be in the province of the
library maintainer. Same with online documentation and even,
eventually, build system. You can how my vision for this manifested by
the library pages in the boost library incubator which requires that
libraries provide certain facilities, (issues list, online docs, etc.)
without requiring that everyone use the same system. Again, this is a
topic way too big for this list, copy or cross post this thread.
> still not clear how to do that (as the Boost docs are again quite
> monolithic in this respect, i.e. don't allow a per-library policy).
Hmmm - I'm seeing just the opposite. To me, the only requirement is
that there be a raw html version. There is not particular requirement
on how one get's there. This has worked out pretty well in my view. It
permits evolution while not requiring a lot of work for older systems.
The one thing that really annoys me about the current system is that I
would like to html for each library downloaded as part of the library so
when I update/download the Boost system or one particular library, I can
just browse the docs without any other extra step.
> if anyone has suggestions on where / how to express that, please let me
LOL - good initiative - just start complaining and offering alternatives.
This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:41 UTC