Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements

Subject: Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2015-04-02 14:59:10

Niall,

thanks for clarifications, I indeed initially misunderstood your suggestion. What you propose, a
certain minimum level of quality/testing to demand, seems quite reasonable to me.

On 04/02/2015 08:51 PM, Niall Douglas wrote:
> On 2 Apr 2015 at 18:09, Vladimir Prus wrote:
>
>>> I would far prefer a scoreboard based system which shows a ranked
>>> list of libraries by quality score. Auto generated from a database,
>>> of course.
>>
>> It would seem that automatic scoring of libraries is both hard technically,
>> and likely to result in arguments.
>
> You're thinking bigger than me. I was thinking automatic clang AST
> tests such as:
>
> * Identifier naming conventions followed: 0 to 100, made up of:
>    * Macro naming conventions
>    * Type naming conventions
>    * enum naming conventions
>
> ... and so on.
>
> I'm thinking the really basic, really uncontroversial stuff. Once all
> those are done, *then* you might starting thinking about more complex
> analysis. But I'd do all the simple scoring tests first - the "box
> ticking" tests for qualifying for Boost entry.
>
>>> Requiring Travis support does not cause the exclusion of any other
>>> form of testing, it just sets an absolute minimum bar to pass - a
>>> minimum bar that I might add is increasingly becoming the bar for ALL
>>> open source projects, so by not requiring it Boost looks behind the
>>> times to the wider open source community.
>>
>> While Travis is a convenient tool for some purposes, it's just tool to
>> run scripts on commits. Having .travis.yml in a repository does not say
>> much about the quality of the code per se. Did you mean a more specific
>> suggestion?
>
> By examining .travis.yml I can tell within a beat if a library is
> maintained or not, even if no other source changes have occurred. The
> simple question is "does this library compile and pass its unit tests
> with the latest Boost release?". If the author updates .travis.yml
> with latest Boost releases then the answer is yes, this library is
> maintained. Even better if travis.yml auto fetches the latest Boost
> release as Antony's script does.
>
> Travis itself isn't hugely important. It's what support for it, or
> any other CI, signifies.
>
>> Also, it does not support Windows, for all I know, whereas Boost is all
>> about portable C++, which very much includes Windows.
>
> Travis support is about absolute minimum bar. I personally believe
> that when searching for an open source library to solve a problem
> that if there is no CI testing in there when Travis is free, that
> sends a very strong message about the lack of dilligence of the
> authors of that library.
>
> Therefore if Boost is about finding quality C++ libraries, those
> libraries need CI testing in there. As libraries in the review queue
> don't appear on the regression testing for Boost, that implies that
> they ought to get some CI testing from somewhere. And Travis is free
> of cost. Though if someone wants to set up a proper Jenkins install,
> that's much better again.
>
> Niall
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com