Contributing to log4net Development

Developer Mailing List

All discussion relating to log4net development takes place on this list. All SVN checkin notifications are also copied to this list.

Mailing List Archives

You can browse the mailing list archives at the following locations:

Subscribe

Subscribe to either the list or to the digest list:

Unsubscribe

To unsubscribe send an email to the relevant email address:

Posting

Most of the guidelines for the log4net-user list also apply to the dev list. Please have a quick read through the guidelines, thanks. To prevent spam, we require you to be subscribed to the list before posting to it.

This is the log4net developer list, it holds discussions relating to the development of log4net not the use of log4net. If you have a question that begins with the word "How" or you are unsure as the the appropriate list to post to then you probably want to start with the log4net-user list.

Post to the list by sending mail to log4net-dev@logging.apache.org.

Source Access

The source for log4net is held in the Apache Subversion source code control repository.

Browsing SVN

Browse log4net SVN repository using ViewCVS.

Anonymous SVN Access

Anyone can checkout source code from our anonymous SVN server. To do so, simply use the following command (if you are using a GUI SVN client, configure it appropriately).

Checkout the logging/log4net module. 

svn checkout http://svn.apache.org/repos/asf/logging/log4net/trunk log4net

If you are not familiar with SVN, the Apache Source Code Repositories page has links to more information on SVN.

Issue Tracking

Many bugs reported end up not being a bug in the log4net code, but are due to incorrect configuration, problems caused by installed applications, the operating system, etc.

Before reporting a bug please make every effort to investigate and resolve the problem yourself. Just reporting a bug will not fix it. A good bug report includes a detailed description of the problem and a succinct test case which can reproduce the problem.

Before reporting an issue please investigate the following information sources for a potential resolution.

Before reporting a bug, you are advised to discuss it on the relevant mailing list first. Search the bug database to see if the bug you are seeing has already been reported. If it has been reported then you can vote for the issue.

Reporting an Issue

If after you have exhausted all other resources to resolve a problem you may want to file a bug report. Please make sure the problem is a bug in Logging and not a bug in your application. Please make sure you provide as much information as possible. Its very hard to fix a bug if the person looking into the problem can't reproduce it. Here is a listing of information which should be included:
  • Version - log4net version, or if from a nightly build, version and date of build.
  • Application Type - Assembly type, i.e. exe or dll, and how your code is launched, e.g. console application, windows application, ASP.NET project, COM+ hosted object, etc...
  • Framework - The .NET framework running the application, name (e.g. MS .NET, Mono, SSCLI) and version.
  • Platform - Computer operating system, version, and hardware platform in use.
  • Configuration - Attach configuration files if they would help track down the bug.
  • Log Files - Review your logs files, produced with internal log4net debug enabled. Submit any relevant sections of the log which help document the bug.
  • Stack Traces - Any stack traces generated by the bug, if any.
  • Example - Example configuration files or web applications which demonstrate the bug. When submitting an example which reproduces the bug, please try to make it as simple as possible.
  • Bug Fix Patch - A patch created using diff -u which fixes the bug. (If you have found a bug fix which can be applied to the code).
  • Description of the Bug - A description of the bug, include observed as well as expected behavior.
  • Miscellaneous - Any other information you feel will help track down the problem.
Just reporting a bug will not fix it. A good bug report includes a detailed description of the problem and a succinct test case which can reproduce the problem. The very best sort of report includes an NUnit testcase which reproduces the issue, this means that we can fix it and that we can be sure that it stays fixed in future! Report a log4net issue here. You will need to login to JIRA before you can submit an issue.

Contributing Patches

Before starting to work on a patch it is probably a good idea to join the log4net-dev mailing list to check that equivalent or complementary work is not already underway. Currently the only supported way of submitting patches to log4net is via the JIRA issue tracking system. The preferred method of generating a patch is a unified context diff against the latest development version in SVN. To do this you should do the following:
  • Get the latest version of the code from SVN, see the section above on Anonymous SVN Access for details on how to obtain the SVN version.
  • Make your code changes to the log4net source. Please follow existing code styles where possible. If adding new API methods or classes then these should be appropriately documented with code comments. Contributions intended for inclusion in ASF products must be licensed to ASF under the terms of the Apache Software License.
  • Generate a unified context diff for the files you have changed. Run the svn diff > patch-file command from the root of the log4net codebase to generate a diff file.
  • If you have added new files these will not be included in the diff. You will need to attach these files separately.
If you are not using SVN then you can still generate a unified context diff using the diff GNU tool with the -u command line options. The GNU tools are available for Windows as part of the Cygwin package. If you are unable to generate a diff please submit each file separately and place block comments around each code change to highlight the differences. In order to submit your patch please follow the following steps:
  • Create a new issue for your patch. On the log4net issues home page select the Create New Issue from the menu bar. You will need to be logged into JIRA in order to create an issue.
  • Select the issue type as appropriate.
  • Prefix the summary with [PATCH]. Enter a description of the changes made, new features, or bug fixes in your patch.
  • Once the issue has been created you can attach your patch file to the issue by selecting the Attach file to this issue operation from the left hand menu. When attaching your patch you must select the Grant license to ASF for inclusion in ASF works option. When attaching a patch please include in the description the baseline version of log4net you used to build your patch, if against an SVN version please include the version number and if from a tag or branch include the repository path.
  • If you have other files to attach, e.g. you have added new files to log4net, then attach each file separately. Please include in the description the name of the file attached and the path it should live in the project.
A notification will be sent to the log4net-dev list once you have created your issue, however it may also be worth mailing the log4net-dev list to encourage the project committers to apply your patch, or at least find out when they may do so.