I recommend this gets reposted to the wiki or the site docs.
On Mon, Apr 28, 2014 at 2:07 AM, Ralph Goers <ralph.go...@dslextreme.com>wrote: > I think we need to develop and post some development “guidelines”, “best > practices” or whatever you want to call it for Log4j 2. Here are some of > the things I would definitely want on it. > > 1. Error on the side of caution. If you don’t understand it, don’t touch > it and ask on the list. If you think you understand it read it again or ask > until you are sure you do. Nobody will blame you for asking questions. > 2. Don’t break the build - if there is the slightest chance the change you > are making could cause unit test failures, run all unit tests. Better yet, > get in the habit of always running the unit tests before doing the commit. > 3. If the build breaks and you have made recent changes then assume you > broke it and try to fix it. Although it might not have been something you > did it will make others feel a lot better than having to fix the mistake > for you. Everyone makes mistakes. Taking responsibility for them is a good > thing. > 4. Don’t change things to match your personal preference - the project has > style guidelines that are validated with checkstyle, PMD, and other tools. > If you aren’t fixing a bug, fixing a problem identified by the tools, or > fixing something specifically called out in these guidelines then start a > discussion to see if the change is something the project wants before > starting to work on it. We try to discuss things first and then implement > the consensus reached in the discussion. > > Of course, the actual coding conventions we follow should also be spelled > out, such as indentation, braces style, import ordering and where to use > the final keyword. > > Ralph > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Cheers, Paul
