[logback-dev] Git as a version control system?

[Thorbjoern Ravn Andersen]

Ceki Gulcu skrev:
>
>> Since you are the project leader, and the primary committer, I 
>> believe you should do whatever you think allows you to be more 
>> efficient while still allowing others to provide patches.
>
> Although I find git's disconnected mode of operation valuable, I'm
> also risk-averse and afraid of new things. So I am looking for reasons
> to tip the balance in favor of git so as to overcome my
> fears. Facilitated collaboration would be an important justification 
> in my
> mind.  It appears that git encourages (by making very easy) project
> forks and to publicize the forked results. I can somehow imagine why
> this would encourage contributions but would also like to hear from
> others.
I think you should set your goals straight.  A low threshold is 
important for others to switch from users of distribution jars to 
tweaking source and build the resulting jars themselves, so the amount 
of pain needed to go through should be minimal.   A good example is 
Glassfish 2 which is close to impossible to get to build as the 
supported build environment is arcane and hard to set up. 

If you want to have another source repository system, so be it, and just 
do it, since you appear to basically have convinced yourself :D

If you want to encourage more collaboration and contributions, I believe 
this is not primarily a technical issue, but more a question of 
community building.  This has proven to be very hard.  Linus and Apache 
have done so.  Sun have failed for most of their open source 
products.    For logback it appears that there are around 10 active 
individuals on the developer list.


>
> The mere fact that people still talk about git speaks volumes about
> the quality of git because Linus is an awful advocate for git. The git
> presentation he gave at Google is embarrassingly inappropriate. See
> http://www.youtube.com/watch?v=4XpnKHJAok8

I will give it a look sometime later - for now I accept your word for it.


>> In my experience changing source repository platform is similar to 
>> changing operating system.  Not something you do everyday.
>
> Once a decade maybe. :-)
Yes.  No need to hurry the issue.  Personally I would not change unless 
there was a killer feature which made a LOT of difference.

At work our primary problem with CVS is the inability to rename files 
and keep the history.  The rest is minor things.  That alone is not 
enough to warrant switching, but we have considered more than once to 
switch to Subversion.


>
>> (and we still use CVS at work, since the benefits of good tools 
>> strongly overshadow the deficiencies of CVS ... for us!).
>
> Interesting point. I guess a similar reasoning applies to migrating
> from log4j to logback.
>
No.  Those things are very different.   The logging platform is "just" a 
component of applications, which happen to throw stuff to disk - most 
people stay with the default appenders etc. [1] The source repository is 
the "operating system" of the source code, and changing that influences 
the work of all developers.

We have not fully switched from log4j to logback, but we switched to 
slf4j to solve the usual log4j + commons logging problem while keeping 
log4j.   After figuring out that log4j is essentially in maintainance 
mode after the logback fork, and that jdk14 logging is basically frozen 
(plus hard to configure externally), we decided that for now we use 
logback as the logging platform.

So, the abstraction quality of slf4j is the primary reason why switching 
logging platforms is a lesser pain than switching source repositories :)

[1]  Our situation is not quite typical.  Our production platform does 
not allow for debuggers or profilers, and most issues are frequently not 
reproducable in test.  Hence I am investigating using logging as a 
forensic tool and less a "all is well" tool.

-- 
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"