Addition of Rule Checkers

[Joel Sherrill]

On Mon, Jul 29, 2019 at 5:23 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, Jul 24, 2019 at 7:16 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> > Hi
> >
> > I just wanted to make sure we followed proper procedures and policies
> when considering rule checkers.
> >
> I guess these comments are germane to the other thread, but I want to
> reflect here a bit.
>
> > 1. The license must appropriate.
> >
> Can you expand what you mean by this?
>

It must be a FLOSS tool -- it can't be proprietary. We use Scan but it has
issues.

It also must be available on the normal set of commonly used hosts.


> > 2. There should be some basic requirements that the tool is expected to
> meet to be fit for purpose
> >
> > 3. The tool must support the range of development hosts used in the
> Community.
> >
> Only if we make it a requirement for developers to check these rules
> locally before submitting patches/commits. If we had a server for
> example that could accept submissions from developers, this would be
> irrelevant?
>

If we relax this rule, then we will end up with a one host tool and have to
have
a server that runs it. Our infrastructure is FreeBSD so saying it supports
the range
of hosts is likely saying it supports our servers, Linux, MacOS, Cygwin,
and MingW

>
> > As a detail, once selected the tool needs to have an RSB recipe.
> >
> Only if you require that checkers must be built-from-source.
>

If we can't get source, then they aren't FLOSS and we are depending on
them coming with distributions and being provided for every host we care
about.

We need something like Phabricator so things can be run against the code
as part of the review/submission process but I want every tool to be
available
to every user.


>
> > For style checkers, I am concerned that they are not integrated into the
> normal development and build process. There is already enough "garbage
> collection" to do and making a special pass. If that's the case, it will
> just be a burden.
> >
> > Just some thoughts. I'm not opposed to this, I just don't want something
> like Coverity where it is only run periodically and only a few people even
> look at it much less fix problems.
> >
> I think that the problem of only running periodically and having few
> eyes/fixes are a bit orthogonal to things you pointed out earlier. I
> think the inclusion of rule checkers will be a good thing, but I also
> agree that how it gets done is important for long-term viability.
>

The less available and less open the tool is, the less likely it is that
anyone
will look at it. I guess I think the two issues are tied together.

If we can add it to the RSB, then it can be built locally and integrated by
us into
the normal build process. Otherwise, we just become a project which is hard
to
submit code to because we are picky and have our own tools at the end.

What does Chromium do with their checker? That would be a good reference to
see where on the spectrum a big project falls.


>
> > --joel
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190729/1a93de5a/attachment-0002.html>