On Mar 31, 2008, at 12:49 PM, Jostein Tveit wrote:
Curt Arnold <[EMAIL PROTECTED]> writes:
On Mar 31, 2008, at 8:39 AM, Jostein Tveit wrote:
./src/test/cpp/logunit.cpp is missing "#include <locale.h>" to
compile on Solaris 8 with Sun Studio 11.
I have only tested RC6, but I think RC7 has the same issue.
I'm sure it would. The issue is that the definition of
setlocale() is apparently made available by #include <stdlib.h>
with the other compilers tested, but is documented to be defined
in <locale.h>.
Should I make a Jira case for this one, or do you handle it?
Not sure if you are saying you got two compilation errors on the
unit tests or after you compiled the unit tests, two unit tests
failed. In either case, it would be great if you could provide
the either the compilation errors or the test failure reports.
That should be two unit tests errors (not compilation errors).
Does it look like LOGCXX-244? In that particular case, the unit
tests fail on MinGW 3.4.5 for an unknown reason perhaps a
problem in the implementation of the standard C++ library on
that platform. In that particular case, I thought that it was
reasonable to note that test failure for that platform but not
hold up a release.
datetimedateformattestcase fails with
Line 213: expected <avr>, but saw <Apr>
In this unit test, the locale is set to fr_FR and the abbreviated name
for the month of April generated by calling SimpleDateFormat and also
by calling DateTimeDateFormatTestCase::formatDate. These are expected
to give the same value, but apparently don't with the
DateTimeDateFormatTestCase::formatDate apparently returning
"avr" (abbreviation for Avril) and SimpleDateFormat::format returning
"Apr". The comparison function is similar but simpler than the
SimpleDateFormat, but should be expected to result in the same value.
The most significant differences is that the
DateTimeDateFormatTestCase::formatDate() uses std::time_put<char> and
SimpleDateFormat would use std::time_put<wchar_t>. It could be that
implementation of standard C++ library does not give consistent
results when the character type is changed.
sizebasedrollingtest fails with
Line 342: true != File("output/sbr-test6.0.zip").exists(p)
Likely that you do not have a "zip" command on your path.
RollingFileAppender uses gzip or zip if the file pattern ends with
".gz" or ".zip" respectively to compress the file after rollover. The
need to have sed, gzip and zip available to pass the unit tests is
documented for the Windows platforms, but all the Unix platforms
tested can with gzip, zip and sed as part of their default tool set.
If the problem seems platform specific or a problem with how the
test is written, I'd be in favor with proceeding with log4cxx
0.10.0 RC7 and fix the problems in log4cxx 0.10.1. Obviously,
we have been anything but "release often" (0.9.7 is almost 4
years old), but hopefully after we get the first release under
our belt, subsequent releases would follow. In the Apache
ethos, end user developers are supposed to be working with
frequent releases, not release candidates or directly with the
SVN. For many years, we have been in the situation of having a
buggy release that does not satisfy the current release
criteria for an ASF release but haven't had a release to which
to direct users. I think publishing RC7 as is overwhelmingly
preferable to leaving log4cxx 0.9.7 as the most recent release.
I totally agree! But I think the unit test compilation problem
should be fixed.
Unfortunately, now less than 72 hours before a trip which means either:
a) Proceeding with the RC7 vote which would allow for a full 72 hours
for vote completion before release.
b) Packaging up an RC8 and shortening the vote window to 48 hours. A
72 hour vote window has been traditional, however recent discussion on
a private mailing list has suggested that 72 hours isn't essential,
just long enough that all interested parties have time to respond.
Since we've had votes in progress for several days now, a shorter
window on an RC8 with just that change should not be a gross violation
of PMC oversight.
c) Waiting at least 10 days for another attempt at a release.
I'd really prefer to get something out and then address the issues
that come up when the user community picks it up in a 0.10.1 and so
on. The problem with not including locale.h in logunit.cpp was there
in RC2 and that it hadn't been reported in the month or so since that
was packaged up, doesn't scream to me that it has to be a showstopper.
However, it is all moot unless some of the other PMC members expect to
cast a vote on the release. I'm going to canvass them privately to
see if they are expecting to vote and whether they would accept a 48
hour vote window on an RC8.
Please provide details as soon as possible, but I would still
encourage testing and am not ready to scuttle RC7.
Tomorrow I will look more closely to why the two tests fails.
Thanks for the feedback.
