Although the details are different, I've also pretty much given up being able to contribute anything to Logback. All my work now is focused on Log4j 2.0 even thought there is no guarantee it will ever be used by anyone. Committing changes to github on a branch no one is ever going to use and I have to constantly keep merging with your repo just seems pointless. It apparently also results in no points for me since none of it ever made it back into the official repo.
As I'm sure you are aware I'm not a fan of the BDFL model so anything you do to loosen the reigns is welcome, especially if it means that Jira issues can be addressed and patches applied when you are on vacation. But FWIW, I knew how you chose to run the project when I first became involved so I'm not really too bent out of shape that my contributions weren't accepted. It just doesn't inspire me to devote a whole lot of time here. Ralph On Feb 14, 2011, at 4:45 PM, Joern Huxhorn wrote: > 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@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. > _______________________________________________ > logback-dev mailing list > [email protected] > http://qos.ch/mailman/listinfo/logback-dev _______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
