Mailinglist Archive: yast-devel (44 mails)

< Previous Next >
Re: [yast-devel] Codeclimate update
On Thu, 30 Nov 2017 11:48:45 +0100
Stefan Hundhammer <shundhammer@xxxxxxx> wrote:

On 30.11.2017 11:14, Josef Reidinger wrote:
Well, advantage against plain rubocop is that it

1. integrate more services -
seehttps://docs.codeclimate.com/docs/list-of-engines

Yes, I looked at that, and what Ruby-relevant things I see beyond rubocop is:

- brakeman: checks RAILS apps for security vulnerabilities

We don't use RAILS, so this does not appear to be relevant for us.


- bundler-audit: Find security vulnerabilities in your Ruby dependencies.

I would hope that our security team keeps looking for those things in the
entire distribution. Other Ruby development teams outside of SUSE don't have
that luxury, so that might really be a plus for them.


- codeclimate-duplication: Tries to find duplicate code. OK, that might be
useful if it really works. But the question is if it works across package
boundaries, e.g. between one YaST package and others. I am doubtful about
that.


There is also reek one (in second table), which have some interesting checks -
https://github.com/troessner/reek . It can be also configured to track your
test coverage ( so it can be used instead of coveralls )


2. visualize it

https://codeclimate.com/github/yast/yast-storage-ng

Is that it, or is there more?

well, it shows

- proportion of ratings of files ( so you know if there is few bad files and
rest is good, or bunch of average rated files )

- there are summary

- there are trends in three dimensions ( e.g. churn one is interesting, also
remaining ones )

- there are list of issues

- there are progress report so you see what changes during last month

- there are overview of per file ratings

- it is connected together, so you can easily click thrue it ( not so easy for
rubocop on CLI )


What do you missing here in visualization?



3. have rating, so it is not plain pass/fail, but allow to see something
like worse, but still not above limit.


https://codeclimate.com/github/yast/yast-storage-ng
https://codeclimate.com/github/yast/yast-installation
https://codeclimate.com/github/yast/yast-network

Hm...

Sorry, I have not mind reader. I have no idea what you dislike here.


4. provides badge for project, so it shows external people some idea about
code quality

If it's badges we are after, I can offer you as many as you like - colored,
black and white, whatever.

But I am not sure how many users and customers care about that. As Arvin
mentioned, the number and severity of bugs and our response time for a first
reaction and until a fix is released will matter a lot more to them. But none
of that is something we make easily accessible to the public.

Badges are not for users nor customers. It is for external contributors to get
idea about project state like code quality, test coverage, documentation
coverage quickly.

It is current trend for public project to show quickly its state. See e.g.
trending projects on github like:
https://github.com/antvis/g2
https://github.com/tldr-pages/tldr

So we can be dinosaur like COBOL and avoid any trends and changes and become
legacy that no-one wanted to touch. Or we can try to look around, adapt to
trends and try to attract some attention.



Just my 2 Cents.


Kind regards

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation