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. thoughts? -Mark On 2/7/06, Scott Deboy <[EMAIL PROTECTED]> 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 > COMOTIV SYSTEMS > 111 SW Columbia Street Ste. 950 > Portland, OR 97201 > > Telephone: 503.224.7496 > Cell: 503.997.1367 > Fax: 503.222.0185 > > [EMAIL PROTECTED] > > www.comotivsystems.com > > > > -----Original Message----- > From: [EMAIL PROTECTED] 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 > > >
