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