You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by Scott Deboy <sd...@comotivsystems.com> on 2006/02/09 01:16:30 UTC
Chainsaw releases
Chainsaw is in a bit of a grey area right now with regard to releases - Chainsaw is officially a part of the log4j project, but has its own svn repository. Chainsaw's in gump, but doesn't have a test module.
I want to make sure we're following the right processes (I feel more than a bit awkward that I brought up tests failing during the latest log4j alpha vote when Chainsaw doesn't event have tests), and I'd like us to discuss what the appropriate release process for Chainsaw looks like.
We create releases that are available via Chainsaw's web page in binary form as a zip of jars, a Web Start link, and a Mac dmg.
The dependencies include:
- the most recent log4j alpha jars (1.3alpha7 currently)
- xstream-1.1.2
- commons-vfs-1.0-rc3
- commons-logging-api.jar (not sure of version, Paul?)
- jakarta-oro-2.0.6
What do we agree is the appropriate release process? Does an alpha log4j release imply a Chainsaw alpha release? Are they separate votes? I would like to see Chainsaw remain a part of the log4j project officially - since Chainsaw has integrated log4j features significantly (loggingevent objects, receiver support).
Also, Paul and myself are the only active committers, which would make votes outside the log4j project problematic without help from the PMC.
Thoughts?
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
sdeboy@comotivsystems.com
www.comotivsystems.com
Re: Chainsaw releases
Posted by Curt Arnold <ca...@apache.org>.
On Feb 8, 2006, at 6:16 PM, Scott Deboy wrote:
> Chainsaw is in a bit of a grey area right now with regard to
> releases - Chainsaw is officially a part of the log4j project, but
> has its own svn repository. Chainsaw's in gump, but doesn't have a
> test module.
>
I'd think it would be helpful to consider chainsaw and log4j as
distinct products produced by the log4j subproject or the Logging
Service project. I don't see anything in the Apache bylaws that say
each independently distributed package of functionality needs to have
independent governance.
> I want to make sure we're following the right processes (I feel
> more than a bit awkward that I brought up tests failing during the
> latest log4j alpha vote when Chainsaw doesn't event have tests),
> and I'd like us to discuss what the appropriate release process for
> Chainsaw looks like.
>
> We create releases that are available via Chainsaw's web page in
> binary form as a zip of jars, a Web Start link, and a Mac dmg.
>
> The dependencies include:
> - the most recent log4j alpha jars (1.3alpha7 currently)
> - xstream-1.1.2
> - commons-vfs-1.0-rc3
> - commons-logging-api.jar (not sure of version, Paul?)
> - jakarta-oro-2.0.6
Why not jakarta-oro-2.0.8?
>
> What do we agree is the appropriate release process? Does an alpha
> log4j release imply a Chainsaw alpha release?
I thought the motivation for spinning Chainsaw out into its own CVS
module was so that Chainsaw could had a distinct release cycle from
log4j. So, I wouldn't think that a log4j release implies a Chainsaw
release.
> Are they separate votes?
I would think so.
> I would like to see Chainsaw remain a part of the log4j project
> officially - since Chainsaw has integrated log4j features
> significantly (loggingevent objects, receiver support).
>
> Also, Paul and myself are the only active committers, which would
> make votes outside the log4j project problematic without help from
> the PMC.
>
I've suggested that log4cxx and log4net could be considered products
of the Logging Services project and dispense with independent
governance. Unlike Jakarta (and similar to Xerces), all our products
address a similar domain with similar architectures but use different
programming languages. The opinions of a log4net developer on
log4cxx code would more weight than opinions of one Jakarta
subproject developer on another subproject's code.