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
