Re: Reviewing third-party packages

On 28/07/2017 10:08, Patrick Morris wrote:
> On 28/07/2017 05:54, Steve - Gadget Barnes wrote:
>>
>>
>> On 28/07/2017 00:27, [email protected] wrote:
>>> S, (Andy and Mike)
>>>
>>> Yes, you've hit a couple of pertinent points; and it might make for an
>>> interesting project.
>>>
>>> However, I was looking for a check-list or similar which I can give to
>>> the pertinent dev.teams to ensure that they are 'covering all the bases'
>>> - whereas the question: "have you checked 'everything'?" produces a
>>> rather predictable response.
>>>
>>> I'm thinking someone wiser than I will have written these things down -
>>> just can't find such...
>>>
>>>
>>
>> As a starting point, my personal mini-checklist, for considering
>> including packages:
>>
>> 1. Licensing: Is the project only ever going to be internal? If there is
>> any chance of it's being included in a commercial deliverable then the
>> licence and all of it's dependencies must be "Apache or better" and have
>> a chart of the acceptable permissive licences vs. usage. Basically the
>> licences that we generally have green flags for are MIT, BSD, CC-BY,
>> MMS-PL & PSF. With some yellow flags on Artistic/Perl & Apache.
>> 2. A quick look at the project repository for indications of activity
>> such as recent check-ins, outstanding tickets, age of pull requests,
>> discussion levels & tone on tickets. (Call this an abandonware check).
>> 3. The reputation, on-line & off, of the authors & maintainers.
>> 4. Is it hosted on a host that hasn't announced its own demise.
>> 5. Test coverage &/or Coverity
>> 6. Do the requirements look reasonable for the nature of the package,
>> e.g. I wouldn't expect network or server type dependencies in a screen
>> shot package.
>> 7. Ditto the imports
>> 8. If there are none-Python elements are they about what I would expect,
>> i.e. things that you would expect performance issues with?
>> 9. Support for Python 3 & 2 or at least a clear statement.
>>
> 
> All of the above are good
> 
> You could also use the following to check for known vulnerabilities
> 
> https://www.openhub.net/explore/projects
> 
> Patrick

Excellent point to add to the above along with:
What does a pylint run look like? Not so much the naming constraints but 
the general code quality metrics - of course if the source of a library 
gives a completely clean pylint result it starts off with a lot of 
brownie points in my book.

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com