Subject: Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-30 22:17:37
On 30 Mar 2015 at 18:33, Robert Ramey wrote:
> Insisting on the above would be a significant policy change for Boost.
I think the policy that libraries in the review queue are maintained
has always been policy as we don't admit unmaintained libraries to
Boost. In fact, to my knowledge, we don't (or haven't ever) even
admit libraries maintained by non-individuals. The introduction of
the CMT was to my knowledge the first time a non individual person
ever maintained a Boost library.
I therefore think that the review queue should be purged of
unmaintained libraries appropriately. Once the authors have been
notified and given a chance to update their submissions of course.
> "Cleaning out the Review Queue" based on this policy would be
> quite a change. I would like to hear what the Review Wizard
> and other members of the boost community think about this. I
> don't think anyone can impose such a change unilaterally.
As I mentioned, the newer libraries in the queue mostly have Travis
enabled (from my quick scan), so it appears it's happening anyway for
new libraries. Some of the libraries in the queue have been there for
many years now, but their maintainers have done a great job keeping
them up to date. QVM and Nowide are amongst the oldest, yet are well
maintained - for example Nowide just gained a STL11 only
implementation, so no more Boost dependency.
I think after a purge of the unmaintained libraries, requiring Travis
CI testing might only affect three to four libraries in there, two of
which I just mentioned. The bigger ask than Travis support might
actually be the ask of putting their submissions onto github as
travis doesn't work well with non-github for open source projects.
> > I might add that all the very recently added libraries to the queue I
> > examined _do_ use Travis, though to what depth I do not know.
> > Nevertheless, I find this a very welcome improvement that many of the
> > official Boost libraries could do with.
> I'm certainly in favor of improving our testing coverage. But I'm
> not convinced that travis is the way to do it. In any case, this would
> be a separate topic (I think).
Travis only has four big pros:
1. It's free of cost.
2. It is very flexible, if awkward. Want to test some weird version
of Boost with some weird version of libstdc++ and do a curl push of
results to some RESTful API on your own custom server farm? No
3. It's the only access to OS X CI testing for almost everyone as OS
X costs a bomb for licensing. BTW, I developed a system for remotely
debugging a segfaulting OS X unit test on Travis, anyone who needs it
4. It's very well integrated with other open source CI web tooling
such as Coveralls. CI status integration with github, especially pull
requests, is excellent.
Everything else about Travis is negative compared to alternatives,
including a lousy UI which gets fussy very quickly, and no (easy) way
of debugging except endless git commit and push cycles.
That said, for testing it compiles and passes unit tests for some
recent clang + GCC + Boost, it really is very good indeed. If you're
already on github and your Boost library is modular, it's a few hours
of your time at most.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/