On 15.06.2012 20:19, Les Hazlewood wrote:
When I created the Logback Extensions project, I did so in the spirit of
most of the *Extensions projects with which I have had experience, e.g.
Wicket Extensions
(http://www.wicketframework.org/wicket-extensions/index.html) and others
like it.
The idea of these extensions projects (and my original intent of Logback
Extensions) is that, with the advent of things like Github, modern Open
Source has changed: people (and many companies) don't want _any_
barriers to committing to and adopting Open Source projects. They want
to submit patches, check out, fork, submit pull requests, make additions
and do whatever they need to Get Their Job Done(tm).
Hello all,
First and foremost, I'd like to express my gratitude to Les for the
logback-extensions initiative. It has prompted interest in
contributions well beyond expectations.
Regarding the CLA, in my experience requesting for CLAs has not been a
hindrance. Developers who made contributions or have expressed
interest in contributing have always signed the CLA when requested to
do so. As a matter of fact, all current members of logback-extensions
*already* have CLAs on file, that is all members except Les**. It's an
unfortunate mishap attributable entirely to me. I'll contact Les in
private for the CLA.
** Les' remarks about the CLA seemed hypothetical until I noticed that
he did not have a CLA on file. How embarrassing!
Beyond the CLA issue, Les also raises good questions about
contribution management. Now is probably a good time to discuss the
purpose of the logback-extensions project.
As I envision it, logback-extesions will host modules with narrower
scope than modules in logback-proper. Hopefully, many of these modules
will be on par quality-wise with modules in logback-proper.
Experimental modules of lesser reliability should be marked as such,
i.e. experimental. Moreover, modules should be able to move in either
direction: from logback-extensions to logback-proper and from
logback-proper to logback-extensions. In practice however, I'd expect
that once a module finds a home, it will tend to stay put.
Logback-extensions' adds value because it reduces coupling with
logback-proper. As I understand it, developers feel freer working on a
particular module without necessarily needing to coordinate with the
core project. For example, logback-extensions can have a different
release cycle than logback-proper. Certain modules may even choose to
live as separate projects with yet a different lifecycle.
I've been also implicitly assuming that logback-extensions would be
distributed under the QOS.ch banner. For example, it would be released
under the ch.qos.logback namespace in Maven central. Similarly,
documentation for modules in logback-extensions modules would be
hosted under http://logback.qos.ch/. Have I misread the situation?
Given the above, my question is:
Should logback-extensions be released under the QOS.ch banner?
[] Yes, logback-extensions should be released under the QOS.ch banner.
[] No, it should be released under a different banner.
[] Maybe (please explain)
Your comments are welcome.
--
Ceki
http://twitter.com/#!/ceki
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
