On 09.03.2012 21:37, Les Hazlewood wrote:
On Fri, Mar 9, 2012 at 5:56 AM, ceki<[email protected]> 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
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
