On 09.03.2012 21:37, Les Hazlewood wrote:
On Fri, Mar 9, 2012 at 5:56 AM, ceki<ceki@qos.ch> wrote:
Hi Les,
Thank you for considering making a contribution to the logback project. The modularization scheme for logback extensions you propose sounds quite reasonable. However, I should mention that logback is already split by logging event type (logback-access, logback-classic) with logback-core providing shared code, applying the core/classic/access separation to the modularization scheme for logback extensions, we could end up in 18 (=3x6) modules (core/access/classic x extensions/json/commmon/groovy/jackson/loggly/). If logback-classic is the only target for logback-extensions, this combinatorial problem obviously does not apply.
I would think that would be at the discretion of the extension module author if they want to support both types of events. At least that makes things a little more decentralized and easier to manage.
More importantly though, I personally cannot and do not wish to commit to the maintenance of logback-extensions. Thus, I would prefer to support logback-extensions as a separate project as far as the code is concerned. However, at the web-site level (http://logback.qos.ch), the two projects could be integrated by allowing you to manage on your own the branch under say http://logback.qos.ch/extensions/.
Thoughts?
I think this is a great idea - it is similar in nature to what many Apache projects are doing these days: there is the main project and also a separate extensions project for community owned/maintained integration. The benefit here is that it provides a central place for the community to work together and provide new features without adding volatility or maintenance overhead to the core project - much nicer than having to fish through Google and random Github projects that may or may not work. (There is an added benefit in that the extension project usually doesn't require any CLA/ICLA to be signed).
Glad you like the approach. I was not familiar with the concept of github organizations. Anyway, inspired by what you have done with the "logback" organization, I've created the "qos-ch" organization (see https://github.qcom/qos-ch/) containing a single repo named logback-extensions with you and me having admin rights. Assuming projects like slf4j, cal10n, logback-*, mistletoe, etc move under that organization, I rather have it named qos-ch rather than logback. Anyway, as mentioned, I am not very familiar with github organizations, and if I've made a mistake, please let me know and I'll correct it promptly.
For starters, I just did the following:
1. I created the 'logback' organization on Github (https://github.com/logback) and made you Owner so you can own/manage it. (Even if we didn't use this mechanism, I figured you'd want to reserve that Github namespace anyway so no one else can squat it)
2. Created an 'extensions-dev' team that initially includes you and I.
3. Created a new 'extensions' repository.
4. Granted the 'extensions-dev' team push and pull access to the 'extensions' repository.
This way, the only thing to do to give people push access to the extensions repository is to just add them to the 'extensions-dev' team, and they can start contributing.
Please let me know if you have any objections to this and I can revert whatever you wish. In any event, you are Owner of the space, so you can do whatever you like. Whatever your decisions, I'm happy to oblige.
Cheers,
Les
P.S. Another benefit of this namespace is that - if you wanted - you can move the logback codebase to the space, create a separate team for that repository and add/remove users as desired if you want to enable development duties for logback proper to anyone you trust.
Github organizations seem like less chaotic way of managing projects. One advantage of person-based approach is the lack of the 300MB barrier which exists in github "organizations". Cheers, -- Ceki http://twitter.com/#!/ceki