|
|
All discussion relating to log4net development takes place on this list. All SVN checkin notifications are also copied to this list.
You can browse the mailing list archives at the following locations:
Subscribe to either the list or to the digest list:
To subscribe to this list send an e-mail to
log4net-dev-subscribe@logging.apache.org.
To subscribe to the digest list sent an e-mail to
log4net-dev-digest-subscribe@logging.apache.org.
To unsubscribe send an email to the relevant email address:
To unsubscribe from this list send an e-mail to
log4net-dev-unsubscribe@logging.apache.org.
To unsubscribe from the digest list sent an e-mail to
log4net-dev-digest-unsubscribe@logging.apache.org.
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.
The source for log4net is held in the Apache Subversion source code control repository.
Browse log4net SVN repository using ViewCVS.
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.
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.
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:
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.
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.