Yeah, I understand that point. As I've been playing around with a development branch thats had a lot of forward churn, I find it difficult to to merge from master.
I can see that it will be easier to de-activate these high count rules and work through the lower count issues and then progressively enable some of these other rules. Since git lets you run hooks on commits, maybe the thing to do there would be to add those hooks to a developer git repo so these things could be implemented over time. I could create a repo with some of these scripts that re-format files so that people could run them on their own dev branches. The stylistic stuff aside, I see it as a good learning tool to help understand java programming better. I think what makes the most sense is treat this like a GSOC project and submit pull requests that could be vetted before they are merged to master. Ron On Aug 26, 2013, at 9:49 AM, Seth Leger <s...@opennms.org> wrote: > I'm concerned about making scripted changes like this en masse. A lot of > these lint cleanups are unnecessary and produce the potential for major > conflicts for people who are merging feature branches into master. The > benefit of removing a bunch of trailing whitespace in 30,000 lines of > code is minimal but the headaches that such a change could make when > merging branches are large. > > The trailing whitespace rule should be marked "ignore" in Sonar. > > The "final" param fixes and such should probably only be done inside a > module where you are currently working or are absolutely sure nobody has > outstanding branches. As we modularize things for OpenNMS 2.0, it's > going to be virtually impossible to guarantee that you're not cleaning > up code that somebody out there is working on to OSGi-ify it. The fewer > merge headaches during this transition the better so I would recommend > pushing your work off until after that. > > Mass scripted Javadoc fixes are probably OK since there are veeeeeery > few hand-edited Javadoc changes that go into existing code. Go wild on > those changes. > > -- Seth > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > opennms-devel mailing list > > To *unsubscribe* or change your subscription options, see the bottom of this > page: > https://lists.sourceforge.net/lists/listinfo/opennms-devel ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
