logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: moving filters to log4j-sandbox
Date Wed, 05 Feb 2003 23:00:52 GMT

At 10:32 05.02.2003 -0800, you wrote:

>The only developers that will go to the trouble will be those enthusiastic
>enough to make a contribution, the ones that need the feedback from the
>general user community.  No normal user will go to the trouble.  I may be
>wrong, but that is my belief.

Making it *very* easy for users will not necessarily result in more
feedback. Users look at the code in order to resolve a bug or an issue
they might have. They act on necessity. If a sandbox component
fulfills a need they have, they will come forward with comments.

The goal of the sandbox is to allow more developers to create
freely. Shortening the release cycle is a different goal.

Stefano Mazzocchi (Cocoon, Avalon, etc.) often quips that the easiest
way to get users working on your code, is to have it do something
useful but with bugs inside. Developers will scramble to fix them and
learn your code in the process.

> > Yes, we can be lax as long as the contents of the sandbox are
> > *not* for
> > release. If the sandbox is just a log4j supplement, then it
> > will demand the
> > same maintenance costs as log4j itself.
>I guess I don't understand why this must be the case.  Is there some jakarta
>apache bylaw that is in effect here?

The rationale for forbidding commons-sandbox releases stems from the
openness of the sandbox. Since any committer can start a project
within the sandbox simply by asking, commons committes exert some
control by disallowing releases. I believe this was a demand from the
PMC or the Board but I am unsure.



To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message