I don't know about "usually", but I can tell you how we do it in curl (which incidentally also matches what I see in several other C/C++ projects). In the curl project we run several static code analy

In the curl project (which is C, not C++) we run clang-tidy on every commit/PR using travis [1] (search for "tidy") and analyze it using lgtm [2]. That's pretty easy to setup. It can be noted that cov

I have the exact same situation in curl. We provide a library and a tool. That both speak TLS and both can disable certificate verification. I think if the application, library, tool, or framework tha

I don't understand the proposed changes. They seem to introduce a huge loop hole in the TLS requirements. First: certificate verification is not just for protecting "sensitive data" that client may se

But if Zephyr is *also* at the same time 93% of the gold criteria it will still only show 193%, right? That might not be as intuitive... I'm not objecting, just clarifying I guess.

Thank you!

Sure OK, but that's also what I object to. That's a totally, completely and all-through subjective measurement that also most likely can be highly debatable in projects. And I'm supposed to give a bin

Yes, thanks, that helps. It does however make me question the value of the criteria. It asks for a document to be present that lists things that a project might or might not do at some point. - projec

My claim is simply that you cannot figure out how easy, how hard or how likely that is based on this "bus factor" number. I claim that you instead wrongly fail to appreciate well-run small projects by

Hi, So for silver level, a project MUST have a "roadmap". Does the project also have to actually implement or work on any of the items in the roadmap? If so, to what degree? If not, what's the purpose

Hi, Since you've now added "bus factor" as a criteria, can someone please explain how this is valuable to users of open source projects? All the availabe tools that determine this factor only run on c

Code reviews are technically easy to operate, sure, but the problem is rarely the actual review process. The problem for all my projects that I don't do as part of my paid job, is to actually get volu

I actually think that in 2017, that is about to start after all, there is *no* and I really mean zero, reasons to not offer all relevant info and services over HTTPS. I don't think there's any room le

This list certainly increases the requirement level a lot and they're all good practices. However, I'm pretty sure none of the projects I'm involved in during my spare time will be able to even reach

On Tue, 8 Nov 2016, Enos D'Andrea wrote: Personally I think the existing critera are pretty good already and we should rather focus on fixing "white spots" that can still be present for projects that

First, let me preface this by saying that this isn't terribly important, its just that we (I) keep coming back to this so I'll elaborate here for the sake of it. So let's first agree to not loose any

This also takes us back to the confusion about project vs product. We have lots of criterium about the project like way of working etc, which really isn't bound to a release at all. And then we have c

Well I didn't say exactly that but I questioned the usefulness of this entry. Nobody told me how the CPE name looked like other than it starts with 'cpe' (including the CPE site and our best practices

Right, because our focus is here on a per-project basis. Also, since most FOSS projects release source code and have many optional dependencies (including mutually exclusive ones), doing automatic sca

I mentioned this to David in private already, but I have this vision that I would like curl (who reached 100% back in March) to also have all, or at least a significant portion, of its dependencies as