|Summary:||Log4j 1.2.16 release - block this issue if a bug must be fixed in the release|
|Product:||Log4j - Now in Jira||Reporter:||Thorbjørn Ravn Andersen <thorbjoern>|
Description Thorbjørn Ravn Andersen 2008-08-02 13:39:52 UTC
Log4j 1.2.16 is a maintenance release corresponding with the official release of version 1.0 of Chainsaw. Chainsaw is an application implementing SocketReceiver so log4j can use the SocketAppender appender to forward logging events to Chainsaw for visualization and analysis. It is intended that all issues which must be fixed before this release, should block this issue in order to keep an up-to-date overview.
Comment 1 Curt Arnold 2008-08-05 16:36:33 UTC
There was already a bug (43313) for the 1.2.16 release. Typically a bug is created for the next release just after the preceding release is cut. Since there are already SVN commits against that bug, I'm expecting that this bug will either be closed as a duplicate or marked as invalid. The list of "blocking" bugs for this bug is not appropriate. It doesn't seem all that different from a list of all open bugs. The list of blocking bugs should be just those that the community deems as essential to be resolved before that particular release. For example, bug 25747 is an enhancement request to improve the diagnostic message that is output when no configuration file could be found and the app does not perform an explicit configuration. The bug was initially filed almost 5 years ago, so for every release since then the community did not feel that that particular issue was so critical that no release could be made until it was fixed. For it to go on the blocking list now, there either needs to be some rationale or an available fix or something to explain why it must be addressed before this particular release. I'd hate to mark it WONTFIX. I don't see it as a priority and likely won't come up to the top of my list, but I don't want to stop anybody else from coming up with a reasonable solution and would be willing to review it. However, I don't want somebody else saying that it must go on my TO-DO list unless there is some critical need. If there are true blocking issues (or issues that may be blocking issues), I'd suggest adding them to 43313. However, limit yourself to one or two of the most critical open bugs until you get a feel for our process and we are able to provide feedback. I could not find a readily accessible definition for blocking issue, so here is mine: A blocking issue for a release is an issue that prevents a release from occurring until the issue is resolved.
Comment 2 Thorbjørn Ravn Andersen 2008-08-05 23:12:50 UTC
(In reply to comment #1) > If there are true blocking issues (or issues that may be blocking issues), I'd > suggest adding them to 43313. However, limit yourself to one or two of the > most critical open bugs until you get a feel for our process and we are able to > provide feedback. > > I could not find a readily accessible definition for blocking issue, so here is > mine: > > A blocking issue for a release is an issue that prevents a release from > occurring until the issue is resolved. A few weeks ago there was 130 open issues on log4j most of which were NEW. The blockers to this issue that I put in are those I think should go in 1.2.16 to warrant a new release, and left the rest outside. So, this is in my eyes a simple way to determine if the goal has been reached or not.