[logback-dev] Logback source code organization and extensions

[Les Hazlewood]

On Fri, Mar 9, 2012 at 5:56 AM, ceki <ceki at 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).

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.