[logback-dev] Running the logback project as a commitocracy

[Joern Huxhorn]

Hi Ceki,


On 14.02.2011, at 18:05, Ceki Gülcü wrote:

> Hello all,
> 
> I am considering running the logback project as a commitocracy. The idea is to settle non controversial questions by consensus. However, whenever a decision cannot be reached by unanimous agreement, a vote is called for. The commit-point for or against a motion are summed, the total accumulated commit-points determining the outcome.
> 
> Developers earn one commit point per day for every day in which they commit code to the project.
> 

I'm not sure about the difference to the current mostly-BDFL way since only you will be the one that decides if a commit will actually enter the blessed repository at https://github.com/ceki/logback/ (or https://github.com/ceki/slf4j/ for that matter).
I may be mistaken but I think not a single patch-submission by me has been applied without change in the past, even though I tried to work completely according to coding guidelines etc.

Examples are http://bugzilla.slf4j.org/show_bug.cgi?id=112 and http://bugzilla.slf4j.org/show_bug.cgi?id=70 or my SLF4J proposal concerning VarArgs over at https://github.com/huxi/slf4j/tree/slf4j-redesign

At the moment I could really use some support for Lilith concerning creation of both LoggerEvent and AccessEvent instances since I'd like to create those events myself to format them using Logback formatters. This isn't possible right now.

See TODO in https://github.com/huxi/lilith/blob/master/lilith/src/main/java/de/huxhorn/lilith/tools/formatters/AccessFormatter.java and https://github.com/huxi/lilith/blob/master/lilith/src/main/java/de/huxhorn/lilith/tools/formatters/LoggingFormatter.java 

I could obviously restart the old http://jira.qos.ch/browse/LBCLASSIC-45 about dumb, accessible data types for events instead of putting initialization logic into them and I could also just implement them all over again, with the very faint chance that my changes may actually be included.
But I actually don't have too much hope anymore which, in turn, is seriously hampering my motivation to even try. I submitted a bug report nearly a year ago about this instead: http://jira.qos.ch/browse/LBACCESS-12

The most depressing thing so far was your comment at http://bugzilla.slf4j.org/show_bug.cgi?id=112#c5 since, in my opinion, we should *obviously* be better than the JDK. If the JDK fails to perform a sober toString(), exploding with a StackOverflowError, then I wouldn't exactly expect a logging framework to be able to tell me what is wrong but I would definitely be pleasantly surprised if it just was.

The fix that you implemented in https://github.com/ceki/slf4j/commit/1d4547f0735b4f7bf185e5f39bb522da492855ec is actually just returning "[FAILED toString()]" instead of my suggested output "[!!!fully.qualified.ClassName at identityHashCodeInHex=>fully.qualified.Throwable:ThrowableMessage!!!]".
The troublesome exception is essentially still eaten up. The fact that it is actually printed to the console doesn't really help, either. I'm using a logging framework so I don't have to scan the console output.
My suggestion/implementation would have contained the information which class was the problematic one and also what, exactly, the actual problem was.

> For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice.
> 
> git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l
> 
> At present time, the commit-points for the logback project:
> 
> Ceki Gulcu 486 commit-points
> Sebastien Pennec  164 commit-points
> Tomasz Nurkiewicz 10 commit-points
> 

The main problem with this heuristic is that even if I did a complete rewrite of the whole Logback project over a timeframe of two years and you'd just love it and decided to take all of my changes you'd still apply (merge) my changes on a single day giving me exactly one commit-point. Does not seem to be very fair to me.
I think this does only work for non-distibuted repositories with multiple commiters  but not for DVCS with a single blessed repository.

> A committocracy may be less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status immediately (after their first commit).

I'm not sure if I really understand you correctly...
Are you really suggesting to give up the blessed repository concept and add just about everyone as a Collaborator (as GitHub calls them)? I think the default GitHub way of working with pull-requests is a much better and safer way of work.

> 
> Your comments welcome.
> 

I hope so ;)

Sorry for ranting but I had to get all of this out of my system.

Cheers,
Joern.