$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-03-17 15:04:38
On 03/17/17 17:50, Stefan Seefeld via Boost wrote:
> On 17.03.2017 10:40, Andrey Semashev via Boost wrote:
>> On 03/17/17 16:13, Peter Dimov via Boost wrote:
>>> Paul A. Bristow wrote:
>>>
>>>> So we must NOT just wipe the slate!
>>>
>>> All right, all right. If you like your slate, you will keep your slate.
>>>
>>> How about we just change our page
>>>
>>> http://www.boost.org/development/bugs.html
>>>
>>> to encourage people to submit pull requests (or, failing that, Github
>>> issues) instead?
>>
>> I'm ok about recommending PRs but not issues. Bugs should be reported
>> to the system chosen by the library maintainers. For some, it is still
>> Trac.
>
> I suggest each library gets its own home page (on
> http://boostorg.github.io/
> exist yet), which contains some boilerplate (default) project info with
> pointers to docs, issue tracker, and other project-specific info.
> Library maintainers can then customize that page according to their own
> needs.
>
> (I'm already using that approach for http://boostorg.github.io/python/,
> but this is obviously not yet advertised from Boost's main website.)
I've done that for my libraries, only I used README.md for that. For
example:
https://github.com/boostorg/log
It seems appropriate since that file is visible online and will get
checked out by default if the user clones git. It is also distributed in
Boost releases.