Yeah, if we did the changes little-by-little it would make merging easier. I know I sounded a little crotchety in my earlier message but I definitely want to see a lot of this lint stuff cleaned up as well. I think that having a nice, clean, well-documented codebase is a definite plus when advertising OpenNMS to the world of potential users and developers. And if you keep up your best practices in implementation code, it makes it easier and less error-prone to layer abstractions (like OSGi, ORM, etc) on top of the code.
It would be nice to have a way to call a "heads up" to the developers out there so that we could alert everyone that big changes are coming to the code if we did want to do some lint cleanup en masse. The last change like this was the slf4j logging update from DevJam 2013 and a heads-up wasn't really needed since most of the developers were in the same room. :) Some ideas that might make this process smoother: - A way to say "heads up! new code incoming!" to developers with outstanding branches - A script that could test merges to active branches and alert you if the conflicts are high before you push (so you know beforehand how much pain you are inflicting on others) - Making it easier to Sonar your new code so that new code is always lint-free In the meantime, I'm a big fan of de-linting any files that you happen to be editing. If you are fixing a bug in a class, go ahead and clean up the modifiers and javadoc! You're going to be running the code anyway to test the bugfix so you might as well do some spring cleaning at the same time. -- Seth On 8/26/13 11:44 PM, Ronald Roskens wrote: > 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 ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&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
