On Jan 27, 2007, at 9:54 PM, Jacob Kjome wrote:
...
I don't think that's necessary. Just mention all the branches you
fix something on. The fixes can be different. If they are, a
short explanation of the difference would be good.
Maybe my subscription to [EMAIL PROTECTED] is botched, but
I didn't see any SVN commit messages from the recent bug flurry.
JIRA (used by log4cxx and log4net) has nice SVN integration, but
log4j uses Bugzilla and does not. I personally like to record to SVN
revision in the comments when closing a bug report and start the
commit message with "Bug xxxxx: ..." , so it is easy to cross-ref the
bug reports with the SVN activity.
Keep in mind, I'm not saying that every bug should be fixed in
1.2. We might just say "too risky for 1.2, but perfectly fine for
1.3". I'm just saying that for some stuff that was reported on
1.2, fixing it on the HEAD and saying the bug is resolved might be
premature. We may also want an equivalent fix on the 1.2 branch.
Maybe we should come up with a guideline of what kind of issues are
up for fixing on the 1.2 branch. Of course, moving 1.3 out the
door would answer this question for us. 1.2 would become legacy
and we probably wouldn't have to concern ourselves with it much
anymore. We just have to make sure there's a good migration path
for users to 1.3, where they mostly drop in 1.3 and logging
continues to run as they had with 1.2, along with new capabilities
they can take advantage of in the future.
>I have marked some things fixed, but perhaps prematurely. Before
I mark
>things fixed, I actually need to understand the process... What
do you
>suggest?
>
I can't say I know for sure. I think others, especially those who
have been more involved with the last couple releases of 1.2.xx
should put in their $0.02 here. Personally, I think 1.2.xx is a
drag on the project. However, as long as 1.3 is not ready for
release, it will be necessary to actively maintain 1.2.xx.
Or, we just drop 1.3 like a bad habit and begin development of 2.0
with more clear goals in mind. 1.3 was Ceki's vision, but he is
currently more involved with SLF4J and Logback. When we lost
active contributions from Ceki, I think 1.3's vision was lost as
well. It started as an incompatible departure from 1.2.xx. Others
saw problems with the incompatibility (including myself) and tried
to make it more compatible. But now it's just a mix. With
attempts at keeping compatibility, we lost flexibility. But we
still have incompatibility. So, now we have the worst of all
worlds. We can't implement some new features for compatibility's
sake and it may or may not be possible to obtain the goal of full
compatibility. At this point, I think we should just drive forward
with compatibility as a top priority, especially since that seems
to be the prevailing opinion of the current active developers. If
we gain compatibility, we keep the Log4j community and can always
start fresh with a new vision for 2.0 if we want to move in new
directions without limits upon our flexibility.
So, to summarize, I think we should decide whether we want to do a
1.2.15+ release. Is it worth the time and effort? Is the 1.3
track where we want to go as far as incremental, 1.2.xx compatible,
development goes or is it a dead end? If we decide it's where we
want to go, then I think we should probably go there, full steam
ahead, and not look back at 1.2.xx other than in exceptional
cases. And, of course, get an official release out within a few
months. If it's a dead end, then I think we should create a 1.3
branch to store it for posterity, continue with the 1.2 branch as
the primary production branch and move on to 2.0 development on the
trunk (assuming someone has a relatively clear 2.0 vision and is
willing to lead the effort). And, finally, we'll need to consider
whether efforts elsewhere deserve more attention; that is whether
Log4j represents the future of logging or whether it's been
superceded, either technically or by sheer force of development
activity. I don't presume to answer this question. I'm just
laying it out there, as it's been in my mind for a little while.
thoughts?
Jake
I think the best path forward is to provide maintenance releases for
log4j 1.2.x, consider log4j 1.3 a development dead-end and initiate
log4j 2.0 development to target JDK 1.5 and later. I've expressed
that sentiment previously, but will reiterate why I think each of
those actions are justified if anyone wants to ask.
Elias has a particular interest in driving log4j 1.3 forward. I've
spent a large amount of my development time over the last few years
trying to improve the compatibility of log4j 1.3 relative to log4j
1.2, however I never really thought that was the best use of my time
and am totally fine with Elias working on log4j 1.3 within its
mandate (compatibility consistent with its version number and
reasonable expectations of early adopters) while log4j 2.0
development gets off the ground. Hopefully, log4j 2.0 could quickly
(well at least relative to our recent development process) evolve to
where log4j 1.3 could be abandoned and log4j 1.2 only maintained for
logging on JDK 1.4 and earlier and legacy applications.
One particular area that I would love Elias to review is the
org.apache.log4j.Scheduler classes. The log4j 1.3 Gump tests have
been failing occasionally for months now due to problems with either
the tests or implementation, though the problem rarely if ever seen
in the development environment but only on the Gump build. Mark
Womack spent a considerable amount of effort adding diagnostic code
to try to understand the nature of the failure, but I'm not sure if
he ever got to the source of the problem. I'm fairly confident that
org.apache.log4j.Scheduler replicates capabilities in
java.util.concurrent integrated into JDK 1.5. I believe that the
configureAndWatch methods on the PropertyConfigurator and
DOMConfigurator were rewritten to use org.apache.log4j.Scheduler. I
would not have a problem with reverting them back to something closer
to their log4j 1.2 implementation if that would eliminate the Gump
failures.
I think the logging API war has been won by java.util.logging, hard
to beat an API that is shipped with the JDK. However, there is not a
body of java.util.logging compatible appenders and configurations (to
my knowledge) that provide a set of capabilities equivalent to
log4j. I would like to see most components of log4j 2.0 to be
decoupled from the logging API and to be best the implementation for
java.util.logging and org.apache.log4j and for any new and novel
logging API. I've hinted at some other aspects of my vision for
log4j 2.0 but haven't tried to lay out a huge treatise on what I
think log4j 2.0 should be since I hadn't put the time in to see if I
could realize in code the thoughts in my head and wasn't sure that
the audience was there. I've been trying to get a log4cxx release
out, but I have longed to be able to start some sandbox efforts to
put some code behind my ideas and get some feedback and something
that the community can start building on.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
