Feasiblity of transferring this to spotbugs organization about find-sec-bugs HOT 2 OPEN

I am not sure I understand the request.

What would the consolidation implies ? Documentation for tools?

from find-sec-bugs.

We tend to get tickets at spotbugs due to this plugin as well as others. Its critical path enough that we internally use it for various testing. When looking at the more critical projects, it felt like possibly having all the tools in the same place might make sense where the original authors come in with same permissions as they do now including gaining access to rest of spotbugs if not already having it. That way it may be easier for both users and contributors to know to look in one place for all things spotbugs.

This originally was becoming a concern with the intellij spotbugs plugin because they wrote some wonderful tool that spammed us so heavily so we started discussing feasibility of bringing in repos that are most often associated with spotbugs to avoid such spam as we would have more control to direct folks to the right repo within the ecosystem as well as possibly release ourselves when we get enough out of sync that things may break.

Looking here there are a lot of other repos probably beyond the scope as I didn't look into them specifically. And our original want sort of died for the time being once we got some attention on intellij and few other plugins that the spam mostly stopped.

So as to consolidation, would only mean repo moved as-is (transferred) and just living under spotbugs org. Nothing more than that. Then that would gain a good number of extra contributors, not that they would contribute or anything but at least make it more visible. Another option would be that we simply fork them but the case with some repos is they move slow are not watched well which wouldn't really help.

For now though I think our need to do so is less. The internal team on spotbugs was ok with poking around to see and my original wording on various projects may have come off not being super clear that it was to be as-is with same permissions so you lose nothing and even maintain your release process as-is. Maybe even take on parts of spotbugs that auto release via github actions so anyone potentially could release without having to jump hoops with sonatype.

For me personally, I own the spotbugs-maven-plugin and I'm typically the only contributor there as others are gradle users (and I hate gradle) but I've also become somewhat more active on spotbugs itself recently mainly due to lack of releases occurring. That said, there would also be no changing build systems either. I know when we asked fb-contrib/sb-contrib they were concerned we would force them off ant. But to each their own as far as that goes.

So its fine to do nothing, was more to plant seeds as we move forwards. We were also rather dormant on spotbugs most of last year and that was sort of a driver too as myself and few others that were either not maintainers suddenly gained enough access that we were able to get it back on track and it is pretty active now. Thankfully I happened to have the keys to the entire thing and just was not aware :)

from find-sec-bugs.