You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by Curt Arnold <ca...@apache.org> on 2008/03/29 03:55:05 UTC
[VOTE] log4cxx 0.10.0 release candidate 6
log4cxx 0.10.0 RC6 is now available for review for release on the
unofficial builds area. This release candidate is strictly provided
for consideration for release, may be withdrawn and will be removed
from the publication location at the conclusion of the voting period.
RC6 is currently available at:
http://people.apache.org/builds/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0-rc6.tar.gz
MD5(apache-log4cxx-0.10.0-rc6.tar.gz)= 4f84d47d56e5c865e000f8e2fff46d3f
http://people.apache.org/builds/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0-rc6.zip
MD5(apache-log4cxx-0.10.0-rc6.zip)= f8b51fc62efea7a44e6046ba901cadae
The corresponding web content can be viewed directly from the staging
SVN:
http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4cxx/index.html
The corresponding source is available at:
svn co http://svn.apache.org/repos/asf/logging/log4cxx/tags/v0_10_0-rc6
log4cxx 0.10.0 RC1, RC3, RC4 and RC5 were withdrawn before publication.
I believe that the release candidate is viable for release with two
condition, the publication of a corresponding 1.0b5 of cpptasks and
the conclusion of a vote by April 2. Rev 158 of cpptasks was used in
the preparation of the release candidate and the generated project
files should not change. I'm a project admin of cpptasks and intend
to have that release out tomorrow.
The change log has a prospective release date of 2008-04-02, if
procedural issues make that date unobtainable then a rebuild to change
the date will be necessary.
The download links in the staged and embedded web content point to the
anticipated location after the release is completed. The mirrors link
will bring up a list of mirrors, but they won't have the file yet.
The mirrors page will not be displayed with Safari due to an known
issue with Safari.
Unzipping the .tar.gz may result in a warning message that a lone zero
block. That is a known issue with Maven (and previously with Ant) and
does not affect the usability of the archive.
The release candidate was prepared using the following software
(listed in order of impact on contents of the release):
doxygen 1.4.6
cpptasks rev 158 installed as 1.0b5.
Apache Maven 2.0.8
APR 1.2.11 source unzipped as a sibling to the log4cxx directory.
APR-Util 1.2.10 source unzipped as a sibling.
Ubuntu 6.06.1-desktop-i386 (using VM from http://isv-image.ubuntu.com/vmware/)
gcc 4.0.3
Sun Java 1.6.0-b105
Attempting to build the release image from a non-Unix platform should
produce flawed Xcode projects. However, any Unix derived OS would be
expected to product relatively close approximations of the release
candidate. The following steps can be used to prepare local builds of
the release candidate for comparison:
tar -xvzf apr-1.2.11.tar.gz
mv apr-1.2.11 apr
tar -xvzf apr-util-1.2.10.tar.gz
mv apr-util-1.2.10 apr-util
export PATH=~/apache-maven-2.0.8/bin:$PATH
svn co http://svn.apache.org/repos/asf/logging/log4cxx/tags/v0_10_0-
rc6 log4cxx
cd log4cxx
mvn site assembly:assembly
The contents of the src directory should be identical to the src
directory of the SVN tag. The contents of the root directory should
be identical to the SVN tag except that it does not contain doap-
log4cxx.rdf which provides the description of the log4cxx project for http://projects.apache.org
and will contain "configure" and associated files generated by
Autoconf.
The site directory is generated by Maven and the projects directory is
generated by cpptasks the raw output of both which are tweaked by the
Ant script during assembly preparation.
mvn rat:check can be used from the root directory to generate a report
on the presence of Apache License Headers, NOTICE and LICENSE files.
The report will be produced in target/rat.txt. The only source files
without License Headers are in src/test/resources/witness which are
comparison log files used during the unit tests and "configure" and
related files which are either MIT licensed or GPL licensed with a
special exemption for programs that contain a configuration script
generated by Autoconf.
The release candidate has no internal markings that it is not an
official release. If accepted, the archive files will simply be
renamed and placed in the main distribution directory for
synchronization to the mirrors and a digital signature will be prepared.
Release will require at least 3 +1 votes from Logging Service PMC
members. However, votes from other parties and any feedback or
experiences with the release candidate are greatly desired. Given the
current makeup of the project, I would expect the PMC members would
verify the procedural and legal issues themselves (which is their
major responsibility on a release review) but would rely on community
feedback the content of the release. It would be helpful if you would
report any observations, particularly successes or failures building
from the release candidate (compiler vendor and version, platform,
etc) along with your +1, 0 or -1. PMC members should identify their
votes as binding. I'd expect that PMC members would hold their votes
until there is some feedback from the user community. This will be a
combined PMC and log4cxx-dev vote, a separate PMC vote will not be
called.
Unless the candidate is withdrawn, voting should be open until 18:00
GMT 2008-04-02. All discussion should occur on log4cxx-dev@logging.apache.org
.
For background on Apache voting, release procedures, etc:
http://www.apache.org/dev/release.html
http://www.apache.org/legal/src-headers.html
http://www.apache.org/foundation/voting.html
The most significant changes since RC2 are the inclusion of the
generated "configure" program and a rework of socket connections which
affect TelnetAppender and SocketHubAppender.
Fwd: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Curt Arnold <cu...@comcast.net>.
FYI: All discussion should occur on log4cxx-dev.
Begin forwarded message:
> From: Curt Arnold <ca...@apache.org>
> Date: March 28, 2008 9:55:05 PM CDT
> To: Log4CXX Dev <lo...@logging.apache.org>
> Cc: Logging General <ge...@logging.apache.org>
> Subject: [VOTE] log4cxx 0.10.0 release candidate 6
> Reply-To: "Logging General" <ge...@logging.apache.org>
>
> log4cxx 0.10.0 RC6 is now available for review for release on the
> unofficial builds area. This release candidate is strictly provided
> for consideration for release, may be withdrawn and will be removed
> from the publication location at the conclusion of the voting
> period. RC6 is currently available at:
>
> http://people.apache.org/builds/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0-rc6.tar.gz
> MD5(apache-log4cxx-0.10.0-rc6.tar.gz)=
> 4f84d47d56e5c865e000f8e2fff46d3f
>
> http://people.apache.org/builds/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0-rc6.zip
> MD5(apache-log4cxx-0.10.0-rc6.zip)= f8b51fc62efea7a44e6046ba901cadae
>
> The corresponding web content can be viewed directly from the
> staging SVN:
> http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4cxx/index.html
>
> The corresponding source is available at:
> svn co http://svn.apache.org/repos/asf/logging/log4cxx/tags/v0_10_0-
> rc6
>
> log4cxx 0.10.0 RC1, RC3, RC4 and RC5 were withdrawn before
> publication.
>
> I believe that the release candidate is viable for release with two
> condition, the publication of a corresponding 1.0b5 of cpptasks and
> the conclusion of a vote by April 2. Rev 158 of cpptasks was used
> in the preparation of the release candidate and the generated
> project files should not change. I'm a project admin of cpptasks
> and intend to have that release out tomorrow.
>
> The change log has a prospective release date of 2008-04-02, if
> procedural issues make that date unobtainable then a rebuild to
> change the date will be necessary.
>
> The download links in the staged and embedded web content point to
> the anticipated location after the release is completed. The
> mirrors link will bring up a list of mirrors, but they won't have
> the file yet. The mirrors page will not be displayed with Safari
> due to an known issue with Safari.
>
> Unzipping the .tar.gz may result in a warning message that a lone
> zero block. That is a known issue with Maven (and previously with
> Ant) and does not affect the usability of the archive.
>
> The release candidate was prepared using the following software
> (listed in order of impact on contents of the release):
>
> doxygen 1.4.6
> cpptasks rev 158 installed as 1.0b5.
> Apache Maven 2.0.8
> APR 1.2.11 source unzipped as a sibling to the log4cxx directory.
> APR-Util 1.2.10 source unzipped as a sibling.
> Ubuntu 6.06.1-desktop-i386 (using VM from http://isv-image.ubuntu.com/vmware/)
> gcc 4.0.3
> Sun Java 1.6.0-b105
>
> Attempting to build the release image from a non-Unix platform
> should produce flawed Xcode projects. However, any Unix derived OS
> would be expected to product relatively close approximations of the
> release candidate. The following steps can be used to prepare local
> builds of the release candidate for comparison:
>
> tar -xvzf apr-1.2.11.tar.gz
> mv apr-1.2.11 apr
> tar -xvzf apr-util-1.2.10.tar.gz
> mv apr-util-1.2.10 apr-util
> export PATH=~/apache-maven-2.0.8/bin:$PATH
> svn co http://svn.apache.org/repos/asf/logging/log4cxx/tags/v0_10_0-rc6
> log4cxx
> cd log4cxx
> mvn site assembly:assembly
>
>
> The contents of the src directory should be identical to the src
> directory of the SVN tag. The contents of the root directory should
> be identical to the SVN tag except that it does not contain doap-
> log4cxx.rdf which provides the description of the log4cxx project
> for http://projects.apache.org and will contain "configure" and
> associated files generated by Autoconf.
>
> The site directory is generated by Maven and the projects directory
> is generated by cpptasks the raw output of both which are tweaked by
> the Ant script during assembly preparation.
>
> mvn rat:check can be used from the root directory to generate a
> report on the presence of Apache License Headers, NOTICE and LICENSE
> files. The report will be produced in target/rat.txt. The only
> source files without License Headers are in src/test/resources/
> witness which are comparison log files used during the unit tests
> and "configure" and related files which are either MIT licensed or
> GPL licensed with a special exemption for programs that contain a
> configuration script generated by Autoconf.
>
> The release candidate has no internal markings that it is not an
> official release. If accepted, the archive files will simply be
> renamed and placed in the main distribution directory for
> synchronization to the mirrors and a digital signature will be
> prepared.
>
> Release will require at least 3 +1 votes from Logging Service PMC
> members. However, votes from other parties and any feedback or
> experiences with the release candidate are greatly desired. Given
> the current makeup of the project, I would expect the PMC members
> would verify the procedural and legal issues themselves (which is
> their major responsibility on a release review) but would rely on
> community feedback the content of the release. It would be helpful
> if you would report any observations, particularly successes or
> failures building from the release candidate (compiler vendor and
> version, platform, etc) along with your +1, 0 or -1. PMC members
> should identify their votes as binding. I'd expect that PMC members
> would hold their votes until there is some feedback from the user
> community. This will be a combined PMC and log4cxx-dev vote, a
> separate PMC vote will not be called.
>
> Unless the candidate is withdrawn, voting should be open until 18:00
> GMT 2008-04-02. All discussion should occur on log4cxx-dev@logging.apache.org
> .
>
> For background on Apache voting, release procedures, etc:
>
> http://www.apache.org/dev/release.html
> http://www.apache.org/legal/src-headers.html
> http://www.apache.org/foundation/voting.html
>
> The most significant changes since RC2 are the inclusion of the
> generated "configure" program and a rework of socket connections
> which affect TelnetAppender and SocketHubAppender.
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Jostein Tveit <jo...@pvv.ntnu.no>.
Jostein Tveit <jo...@pvv.ntnu.no> writes:
> Curt Arnold <ca...@apache.org> writes:
>
>> On Mar 31, 2008, at 12:49 PM, Jostein Tveit wrote:
>>
>>> 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.
>
> It seems like a bug in the Sun standard C++ library.
> It actually gives different results depending on whether
> std::time_put<wchar_t> or std::time_put<char> is used.
Confirmed as a bug by Sun.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6682914
--
Jostein Tveit <jo...@pvv.ntnu.no>
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Jostein Tveit <jo...@pvv.ntnu.no>.
Curt Arnold <ca...@apache.org> writes:
> On Mar 31, 2008, at 12:49 PM, Jostein Tveit wrote:
>
>> 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.
It seems like a bug in the Sun standard C++ library.
It actually gives different results depending on whether
std::time_put<wchar_t> or std::time_put<char> is used.
--
Jostein Tveit <jo...@pvv.ntnu.no>
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Jostein Tveit <jo...@pvv.ntnu.no>.
Curt Arnold <ca...@apache.org> writes:
>> 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.
I have to dig more into this, but it may be some kind of bug in
the Sun standard C++ library. I have searched the Sun site and
have found some other locale bugs.
>> 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.
You are correct. zip were not install on my Solaris box. After
installing the SUNWzip package, the unit test were successful.
> Unfortunately, now less than 72 hours before a trip which means either:
>
> [list of options removed]
log4cxx is in desperate need of a stable release. As long as the
problems I have found most likely are with regards to the unit
tests, I hope RC7 or RC8 will be released as log4cxx-0.10.0.
You're doing a great job here!
--
Jostein Tveit <jo...@pvv.ntnu.no>
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Curt Arnold <ca...@apache.org>.
On Mar 31, 2008, at 12:49 PM, Jostein Tveit wrote:
> Curt Arnold <ca...@apache.org> 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.
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Jostein Tveit <jo...@pvv.ntnu.no>.
Curt Arnold <ca...@apache.org> 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>
sizebasedrollingtest fails with
Line 342: true != File("output/sbr-test6.0.zip").exists(p)
> 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.
> 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.
--
Jostein Tveit <jo...@pvv.ntnu.no>
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Curt Arnold <ca...@apache.org>.
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>.
>
> I also got 2 errors in the unit tests with Sun Studio 11 64bit
> compilation on Solaris 8. I will dig into the errors tomorrow,
> but at the moment I will not recommend RC6 or RC7 to be
> published.
>
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.
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.
I have seen timebaserollingtest fail intermittently which I've logged
as LOGCXX-260. The test predicts the file names of the per-second
rollover files and an unexpected lag will result in a mismatch between
the predicted file names and the actual file names. The resolution
would be to rework the test to examine the file names in the output
directory and match those to the appropriate files for comparison.
Typically, the problem will go away the next time you run the tests.
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.
Please provide details as soon as possible, but I would still
encourage testing and am not ready to scuttle RC7.
Re: [VOTE] log4cxx 0.10.0 release candidate 6
Posted by Jostein Tveit <jo...@pvv.ntnu.no>.
./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 also got 2 errors in the unit tests with Sun Studio 11 64bit
compilation on Solaris 8. I will dig into the errors tomorrow,
but at the moment I will not recommend RC6 or RC7 to be
published.
--
Jostein Tveit <jo...@pvv.ntnu.no>