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

Subject: Re: [Boost-docs] svn.boost.org wiki
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-07-15 18:06:32

On 15/07/15 01:51 PM, Robert Ramey wrote:
> 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.

I have just done that. (Please follow up as appropriate.)

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

Actually, I didn't mean to discuss my desire to move away from Trac,
only try to figure out how to indicate that in the docs...

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

OK, agreed. My complaint about lacking modularity was about the fact
that the reference to Boost Trac lives outside library documentation, in
a central place (http://www.boost.org/development/bugs.html), so even if
I indicate something different in library-specific docs, it's "too late"...

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

Right.

>
>> So
>> if anyone has suggestions on where / how to express that, please let me
>> know.
>
> LOL - good initiative - just start complaining and offering alternatives.

I think the menu item about "Reporting and Fixing Bugs" belongs into a
library-specific section. In fact, the entire "Development" section
should probably be replaced by per-library documentation.

(Again, this to me is a documentation issue, which is why I'm bringing
it up here.)

    Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...