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> |
Component: | Other | Assignee: | log4j-dev <log4j-dev> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | ulrich.voigt |
Priority: | P2 | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Thorbjørn Ravn Andersen
2008-08-02 13:39:52 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. (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. |