logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From renny.ko...@rubixinfotech.com
Subject Re: Most stable version of log4cxx?
Date Thu, 06 Dec 2007 18:30:14 GMT
Curt -

We are primarily a Solaris shop... so we have Solaris 8  & 10 servers we 
can test on.  We also have Linux (RHES4) systems.
Renny Koshy
President & CEO

--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com



Curt Arnold <carnold@apache.org> 
12/06/2007 01:16 PM
Please respond to
"Log4CXX User" <log4cxx-user@logging.apache.org>


To
"Log4CXX User" <log4cxx-user@logging.apache.org>
cc

Subject
Re: Most stable version of log4cxx?







On Dec 6, 2007, at 8:58 AM, Stephen Bartnikowski wrote:

> Hey Curt,
>
> What's the testing process? How do we the users get involved on that 
> and
> what sort of committment do we need to make?
>
> I think it's important I eke out some testing time out of my 
> schedule to
> help out on that front, since, hey I'm using developer builds of 
> log4cxx on
> FreeBSD, openSUSE, SUSE Enterprise, Fedora, Red Hat Enterprise, 
> White Box,
> and I want to bring it over to Mac OS X Server.

That is a nice set of platforms that compliments the ones that I test 
on.  I currently test on Ubuntu 6.06 and 7.10 on i386 and x86_64, Mac 
OS/X and Win 2K with VC6 and VC7.  I've got a Windows Vista x86_64 
that I need to get Visual Studio 2008 up and running on to test Win64 
builds.  All running as VM's under VMWare Fusion.  I'd like to have 
Solaris using gcc and Sun Studio in my collection of VMs, but 
struggled on previous attempts on setting up a Solaris VM in 
assembling all the needed software.

>
>
> As for the voting process, is there a process there too? Do we need to
> subscribe to general@logging.apache.org to participate?
>

The requirements for an Apache release process is described in the 
following documents (ordered in most binding to least binding)

http://www.apache.org/dev/release.html
http://logging.apache.org/guidelines.html
http://httpd.apache.org/dev/release.html
http://incubator.apache.org/guides/releasemanagement.html#best-practice

The outline of the process would be that a release candidate is 
prepared from a SVN tag and placed at http://people.apache.org/builds 
for review and a vote is called on log4cxx-dev and 
general@logging.apache.org 
  which is open at least 72 hours.  The Logging Services Guidelines 
prescribe distinct votes by the subproject (log4cxx) and LS PMC, but 
those have been held simultaneously in previous log4j releases since 
it ends up as two votes by almost the same set of people.  LS PMC 
members have the only binding votes and at least 3 votes in favor from 
PMC members are required.  Other voters are desired, but only 
advisory.  To get that many votes from the PMC will mean convincing 
members whose primary interest is log4j, log4net or Chainsaw to cross 
lines and vet our release, so the more advisory votes on the release 
would allow the PMC members to with confidence focus on just the legal 
and procedural requirements.  If there is a community in favor of a 
release candidate, then working through the procedural and political 
issues should be achievable.  If there isn't a community, then it is 
likely stuck.


On Dec 6, 2007, at 9:25 AM, renny.koshy@rubixinfotech.com wrote:

> Stephen -
>
> Very good question... I have an offshore dev team who may be able to 
> throw
> in some time testing, assuming there are **documented** tests to 
> run.  They
> are definitely not too good on "ad-hoc" style testing.
>

There are a couple of classes of "testing" that I envisioned:

a) build and unit test testing on different platforms/compiler 
combinations

This type of testing would check that log4cxx builds and passes unit 
tests on a variety of platforms and compiler variations and that the 
INSTALL file properly describes the build process.  The ideal persons 
for this type of testing have a variety of build platforms already 
available and could give a pass/no-pass in just a few minutes.

b) Release reproducibility testing

Confirm that an identical or near identical release can be prepared 
from the SVN.  For log4j, the release build environment has been a 
specific configuration of Ubuntu 6.06-1 and with the exception of 
timestamps within the zip files, releases are bit-for-bit identical. 
Before I prep a release candidate, I'll confirm that I can repeat it. 
It would be good for someone else to confirm that they were also able 
to reproduce the release.

c) Unit tests using diagnostic tools

I'll run the unit tests under valgrind before prepping the release 
candidate.  Anyone who has Purify, BoundsChecker or other tool who 
wants to take a spin would be appreciated.  Anyone with a real app who 
can profile log4cxx would also be appreciated.

d) Application testing

Sanity tests of someone who has an non-trivial app that can report 
would be appreciated.

None of these seem like things that could be effectively out-sourced.

On Dec 6, 2007, at 10:06 AM, Andrew Phu wrote:

> Wow!
>
> I work in a Windows environment.  Are there any instructions on build
> and test?
>
> Thanks,
> An

Check INSTALL and if it leaves any gaps ask on the list.  The release 
would contain at least VC6 project files produced from Ant+cpptasks, 
but for now you have to generate those on your own.




Mime
View raw message