Replies: 4 comments 4 replies
-
I've opened issues with fb-contrib (sb-contrib), find-sec-bugs, and findbugs-slf4j (bug-pattern) to see feasibility of interest in keeping all in spotbugs org. I believe I've worked on all of them at one point or another with most work on fb-contrib. |
Beta Was this translation helpful? Give feedback.
-
fb-contrib responded back already and something I should note here. In no way would we force a team that is maven to be gradle. If they are maven they would remain maven. In fact, if I had my way this project would be rewritten with maven not gradle. There is zero value to using a niche product but I digress. @KengoTODA has no desire to move his adapter here which is both odd to me considering he is a huge part of spotbugs but also because he has error prone so he suggested just forking it here. If we go that route with known well working items, I fear we will hard fork and leave them behind. Its not more work for us but we should consider those as not important and not even consider them at all in that case. Note: I'm very opinionated for sure but really want this community to come together and grant as many that can release that can. We won't survive if people leave and leave us high and dry like we had for a year. Given our some 2.5 million downloads a month, we are nothing small. And it would be awesome if all community members came together but no one can be forced. Its a personal thing in many cases. Just wish we could make this happen, these ideas I think may go no where :( |
Beta Was this translation helpful? Give feedback.
-
In the past I used few times fb-contrib only to understand whether the bugs reported are spotbugs related or not, and what I saw so far from past experiments were a lot of new "noise" warnings reported, where I personally would never report them or (as developer) consider to fix them. So from that point of view I would vote not to merge that one to spotbugs. The original goal of spotbugs was not to report any possible warning, but provide a high quality reports for issues that has to be fixed because they lead to real bugs. Reporting style issues is the job of checkstyle & Co. But - if the original author is interested at all - what I could imagine is to move detectors to spotbugs while enabling/disabling every bug detector individually. |
Beta Was this translation helpful? Give feedback.
-
If the original authors are interested, I have no objections about moving the repositories under the SpotBugs organisation. It should be their decision, and noone should loose rights or access because of the transition. |
Beta Was this translation helpful? Give feedback.
-
I think as a community of tools and in fact some of us work on many of these, would it make sense to try to engage authors and bring them in the fold here so we have a bit more control. I get tickets on some of these addons in the maven plugin and I'm sure others do on others. Not a lot but I think of spotbugs as one large community and think we would be best off treating all parts as part of that community if possible.
Thoughts?
Items for considerations
Do note above all maven based and personally would keep them that way but still think as part of the community and in general usage they go hand and hand with spotbugs so why not be part of spotbugs proper and get these folks to work here too...
Beta Was this translation helpful? Give feedback.
All reactions