struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yasser Zamani <yasser.zam...@live.com>
Subject Re: Would we need to achieve better place in trends ranking?
Date Fri, 10 Nov 2017 10:35:32 GMT


On 11/10/2017 12:58 PM, Lukasz Lenart wrote:
> I have added a Jenkins build to perform a Sonar analysis per push but
> I disabled spamming the dev@ list for now;-)
> 
> https://builds.apache.org/analysis/overview?id=org.apache.struts%3Astruts2-parent
> 
> 2017-11-08 11:18 GMT+01:00 Lukasz Lenart<lukaszlenart@apache.org>:
>> There is a Sonar instance running
>> https://builds.apache.org/analysis/

Thanks! the Sonar instance seems has great analysis.

However, I thought about bring these to our maven build and github 
system. I saw this approach a few month ago with Apache commons-lang. 
When I requested a pull, I saw it fails because I don't add a @since tag 
or because I don't use {} for a one line if statement! (they have 
apache-rat:check clirr:check checkstyle:check in their maven build). 
They also comment if the PR increase or decrease the current test 
coverage [1].

I am thinking about if we can add nice checkers to our maven build and 
git system little by little. The positive point is, at first place i.e. 
the PR or the commit, we block making things worse by failing the build 
if our quality metrics exceed some thresholds.

I know already there are a lot of Sonar issues but maybe we can ignore 
current old ones and fail the build if new ones added at first place 
i.e. a PR or commit :)

Isn't it better to resolve such issues at first place they occur? i.e. 
forcing committer or pull requester to resolve them at place. Or maybe 
you prefer to resolve newly added ones just before release in separate 
commit(s)?

[1] https://github.com/apache/commons-lang/pull/261#issuecomment-289265370
Mime
View raw message