At 02:32 PM 1/27/2007, you wrote:
>
>--- Jacob Kjome <[EMAIL PROTECTED]> wrote:
>
>>
>> Elias,
>>
>> Are you making sure to apply some of the fixes to
>> the 1.2 branch? You mentioned you fixed this on
>> the trunk, but it was specifically reported
>> against 1.2.xx and is blocking the 1.2.15 release
>> tracking issue [1]. I haven't checked SNV, but I
>> just wanted to make sure you were keeping this in
>> mind as you go on your bug fixing tear, which I applaud. :-)
>>
>
>Bug fixing tears come and go. I might be here for a week then disappear :-)
>
>I'm not sure, using Bugzilla, how to mark one bug fixed in one branch but not
>another? Should I open up a separate 1.2-only issue.
>
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.
>Incidentally, I'm thinking maybe that the SyslogAppender should extend the
>WriterAppender. There's this bug:
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=40161
>
>which sort of suggests this as well. Changing the class like this might be
>higher impact than we'd like for 1.2.
>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
