Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?

Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-17 15:16:53

Stefan Seefeld wrote:
> On 17.03.2017 10:40, Andrey Semashev via Boost wrote:

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

Some Boost libraries disable Github issues, presumably for this reason. But 
the main page needs to be simple and clear. It should direct people to 
http://github.com/boostorg/
>. Listing individual preferences on the 
main page doesn't scale.

> I suggest each library gets its own home page (on 
> http://boostorg.github.io/
>, ...

The libraries already get their own pages at 
http://github.com/boostorg/
> - they just need to use their README 
files as intended. If Trac is to be used, disable issues, point people to 
Trac in README. If the /newticket link can set the component appropriately, 
all the better. If not, tell people what to set the field to, explain the 
importance.

But frankly, in my opinion at least, pull requests are much, much superior 
to issue/ticket workflows for our purposes. If you're reporting a bug, put 
the failing test in the PR; this is work that has to be done either way, is 
much easier on the maintainer than describing a problem in words, and CI 
integration means that the compiler output for the failure is immediately 
available in a browser.