Re: [Boost-docs] svn.boost.org wiki

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 
developer's list.

> 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.

> It's
> 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.

> So
> if anyone has suggestions on where / how to express that, please let me
> know.

LOL - good initiative - just start complaining and offering alternatives.

Robert Ramey