logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Womack" <mwom...@apache.org>
Subject Re: [RESULT] Release log4j-1.3a8 official
Date Thu, 09 Feb 2006 02:08:49 GMT
Thanks, Scott.

I guess we need to better define "all tests pass".  All of the tests
passed on the machine I was doing the build on.  If they hadn't, I
wouldn't have even bothered with posting the release.

And I would hope that with a clean checkout (that I use for the
builds) the tests would generally fail on my machine in the same way
they would fail on Gump.  That said, Gump has its own environment, so
it is possible Gump could fail but my machine passes.

The policy should be that if the release manager cannot get the tests
to pass when doing a build, then it is not a build that should be
accepted or even posted.  Project committers need to keep the release
manager honest, and Curt has been playing that role on log4j lately.

What we are seeing with FileWatchdog is intermittent.  It needs to be
looked into, no doubt.  If we were closer to beta or rc, then I would
be uncomfortable with doing the release.  As it is, since I cannot
reproduce, I'll have to instrument the test/code so I'll have a better
chance of figuring it out next time it happens.

What I'd really like to see is an external build environment.  I
submit a job to an Apache hosted system, giving it all the build
related information it needs, it downloads the code, tags it, builds,
tests, packages it and sends me an email with the status and where to
pick up the resulting binaries.  It could even test it in multiple
environments (JDK 1.3, JDK 1.4, maybe even a couple of web app
servers).  It could test it multiple times for a "burn in" period to
catch intermittent possibilities.

I understand that the Geronimo has something like this (gbuild?), and
I talked to Bruce Snyder at ApacheCon, and he said that they were open
to creating a general framework for other projects to use.  Of course,
it sounds like it is based on Maven.  :-)  I just haven't had time to
follow up on it yet.

I know it is a future thing, but if a build were to go through that
process, then I think we could all be a lot more comfortable with
deciding on whether to support a release or not.  But for now it will
have to depend on the release manager and other project members to
make sure the release passes muster in relation to the tests.  And if
something fails in Gump, then it should be taken seriously and
followed up on.


On 2/7/06, Scott Deboy <sdeboy@comotivsystems.com> wrote:
> I appreciate your efforts, Mark, and I realize this is an alpha release so the expectation
of a quality release is lower.  I don't want to get in the way of getting feedback.
> My view is that releases (including alpha releases) shouldn't come to the PMC for a vote
until tests pass.
> Let's have a discussion about releases - do we as a PMC want to have a 'policy statement'
about tests and how they relate to releases?  If we don't want to define a set policy, that's
ok, it's just that -1s can have a negative impact (no pun intended) on the community, and
obviously if we can avoid it we'll be better off.
> +1 on the release, but I'd like us to come to agreement on what our role is w/r/t releases
and tests/alpha and non-alpha releases.
> Scott Deboy
> 111 SW Columbia Street Ste. 950
> Portland, OR  97201
> Telephone:      503.224.7496
> Cell:           503.997.1367
> Fax:            503.222.0185
> sdeboy@comotivsystems.com
> www.comotivsystems.com
> -----Original Message-----
> From: mwomack@google.com on behalf of Mark Womack
> Sent: Tue 2/7/2006 11:33 AM
> To: Logging General
> Subject: [RESULT] Release log4j-1.3a8 official
> +1 Mark
> +1 Curt
> +0 Scott
> There are not enough votes to allow the official release of log4j 1.3
> alpha 8 at this time.
> I am still looking into the file watchdog, but was still unable to
> reproduce yesterday, using the JDK 1.4.  FYI, Gump has not reported
> any test failures in any recent runs.
> -Mark

View raw message