[logback-dev] Logback source code organization and extensions

[ceki]

On 09.03.2012 21:37, Les Hazlewood wrote:
> 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).


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