Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 2010-07-01 at 13:24 -0600, Jonathan Corbet wrote: For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. I've wanted such a metric for a long time. Lines of code is a terrible metric for work done in general, even if you don't want to make a distinction between architectural and other changes. Changeset counts aren't really any better. Among other things, both create poor incentives if people actually start to care about the numbers. That said, I've still not found a better way of trying to measure who's doing the work, especially in the context of a high-bandwidth project like the kernel. If anybody has any ideas, I'm all ears... What I have done in the past is correlate the functions changed by a developer against a callgraph (dynamic[1] or static) of the program. For example, functions deep in the callgraph get more weight and you can sum the weight of all the functions changed by a developer (This does not give much weight to the code of the mainloop which is still a critical piece of infrastructure but except for that, it's usually an interesting metric). I remember trying other per-function weights such as the number of functions calling the function or the number of functions called by the function or the size in bytes of the function but I don't remember if they were really relevant to the final ranking. What might be interesting is assigning a set of relative weights to these different weights to generate the final per-function weight and see if/how this changes the final ranking. I never got time to try this though. Mathieu [1]: I generated the dynamic callgraphs with this thing I wrote: http://cutebugs.net/bozo-profiler/ (there is a tarball to download) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 08:16:34PM +0200, ext Greg KH wrote: Note, I have a bunch of the xorg developers already in our main gitdm configuration file due to me running the numbers a long time ago for a Linux Plumbers conference talk. I think it's somewhere public as well, but I can't find it at the moment. Do you want me to merge what you have done here with that file? So did you find the file? Those trivial patches in gitdm were cooked in a way that lets the kernel stats live nicely. You can grab those either if you want. Thanks, Tiago ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 09:40:50AM -0400, Keith Packard wrote: Not a huge number of changes this week; a couple of bug fixes, some server log cleanups and some Xephyr changes. Summary below, but first I've gone over the bugs in the 1.9 tracking bug: https://bugs.freedesktop.org/showdependencytree.cgi?id=27592hide_resolved=1 I'd like to encourage anyone with an interest to work on these and I think that from now until the release we shouldn't be merging any code which isn't tied to a specific bug. [...] o23938: keys occasionally get stuck with xorg-server 1.6.99.901 There have been a few keyboard fixes in the core server of late; any idea if this bug is fixed now? race condition, afaict still there though rather random to trigger. o23985: Excessive core motion events for subpixel motions This one doesn't appear to have been fixed, on the other hand, it doesn't look really bad -- clients just get too many events. feature request, not a blocker. problem since 1.7 anyway. o24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) I think this one could use re-testing. unlikely to be fixed, but I haven't tested since. some memory corruption, requires a specific keymap to trigger and time. o24856: xorg-server-1.7.1 mouse cursor not moving from MouseKeys This seems to happen only when not using SilkenMouse and/or SIGIO input. I have a vague memory of someone looking at this in the last couple of months? Pull request on list, consider this fixed. o25801: Switching VT re-enables XBell(), ignoring 'xset b off' Trivial to test, and I can't imagine it will be all that difficult to fix. I have yet to find a machine that actually rings a bell so testing is tricky for me. o27804: Enter/Leave event woes with multiple master devices. This one was posted by Peter, and surely looks to be solveable only by Peter. ++ out of cheese error, redo from start ++ None of the commented ones above is a new bug, we've put out 1.7 and 1.8 with them so IMO they are nice-to-fix but not a blocker. Cheers, Peter ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 1, 2010 at 8:45 AM, Tiago Vignatti tiago.vigna...@nokia.com wrote: Hi! On Thu, Jul 01, 2010 at 03:40:50PM +0200, Keith Packard wrote: Not a huge number of changes this week; a couple of bug fixes, some server log cleanups and some Xephyr changes. I got gitdm working with xserver [0] and here are the results from 1.8.0 until 1.8.9.904. Wow, this is awesome! Thanks for doing that, Tiago. snip - If my math is correct, the rate between review + tests + signoffs (386 + 31 + 554) and commits made (441) is 2.2. In short, that's the average number of reviews made per patch that got commit. Since we don't commit patches without a Signed-off-by, it seems that just the Reviewed/Tested/Acked-by are more important on their own. For instance, 386/441 = 88% of commits had a Reviewed-by is pretty impressive. - the delta (302) between lines added and removed are small. I think this is perfectly understandable given the amount of clean-up we had (MAXSCREENS removal, *alloc, PCI stuff, etc) in 1.9 development against the features added. - 39% of changeset represents contributors not affiliated with any company (gitdm -u). Worth to note that Jamey and Mikhail made a huge amount of contribution and I counted as not affiliated - probably wrong. Maybe we can say that X development could survive in some way even not having any company directly contributing there. - Intel, Nokia, Red Hat, Oracle and Apple are on the top five. Other known companies that care about X and desktop like Google, Canonical and etc are far from those on the amount of contribution. - what else? Well, that are just some facts that I got quickly running gitdm here. I don't think that only the xserver represents all graphics development under X.Org community. It's just a portion of it and we would have to include DRI, Mesa, drivers, etc to get a more accurate analysis. It would be cool to run it on Mesa. It will be mostly vmware, but that's certainly a very active and significant part of the graphics puzzle. -- Dan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 06:45:48PM +0300, Tiago Vignatti wrote: [0] On the top of the Jonathan's tree I applied some patches concerning X.Org. I'm cc-ing him also who might be interested to fetch it: ttp://cgit.freedesktop.org/~vignatti/gitdm/ I think you ment: http://cgit.freedesktop.org/~vignatti/gitdm/ :) git://anongit.freedesktop.org/~vignatti/gitdm $ git clone git://anongit.freedesktop.org/~vignatti/gitdm Initialized empty Git repository in /home/gregkh/tmp/gitdm/.git/ remote: Counting objects: 153, done. remote: Compressing objects: 100% (71/71), done. remote: Total 153 (delta 76), reused 153 (delta 76) Receiving objects: 100% (153/153), 44.46 KiB, done. Resolving deltas: 100% (76/76), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Are you sure you set that up correctly? greg k-h ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 07:24:25PM +0200, ext Greg KH wrote: On Thu, Jul 01, 2010 at 06:45:48PM +0300, Tiago Vignatti wrote: [0] On the top of the Jonathan's tree I applied some patches concerning X.Org. I'm cc-ing him also who might be interested to fetch it: ttp://cgit.freedesktop.org/~vignatti/gitdm/ I think you ment: http://cgit.freedesktop.org/~vignatti/gitdm/ yep! :) git://anongit.freedesktop.org/~vignatti/gitdm $ git clone git://anongit.freedesktop.org/~vignatti/gitdm Initialized empty Git repository in /home/gregkh/tmp/gitdm/.git/ remote: Counting objects: 153, done. remote: Compressing objects: 100% (71/71), done. remote: Total 153 (delta 76), reused 153 (delta 76) Receiving objects: 100% (153/153), 44.46 KiB, done. Resolving deltas: 100% (76/76), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Are you sure you set that up correctly? ooops. Should be fixed now. Thanks for checking this all! Tiago ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 08:45:33PM +0300, Tiago Vignatti wrote: git://anongit.freedesktop.org/~vignatti/gitdm $ git clone git://anongit.freedesktop.org/~vignatti/gitdm Initialized empty Git repository in /home/gregkh/tmp/gitdm/.git/ remote: Counting objects: 153, done. remote: Compressing objects: 100% (71/71), done. remote: Total 153 (delta 76), reused 153 (delta 76) Receiving objects: 100% (153/153), 44.46 KiB, done. Resolving deltas: 100% (76/76), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Are you sure you set that up correctly? ooops. Should be fixed now. Yes it is. Note, I have a bunch of the xorg developers already in our main gitdm configuration file due to me running the numbers a long time ago for a Linux Plumbers conference talk. I think it's somewhere public as well, but I can't find it at the moment. Do you want me to merge what you have done here with that file? thanks, greg k-h ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
Tiago Vignatti tiago.vigna...@nokia.com wrote: If I have more motivation I'll try to get some stats comparing different versions of the server development and maybe other modules. Also, if you are interested on different kind of statistics I can run more. Suggestions are very welcome and appreciated (for instance fixing contributor - company)! A year or so ago, someone pointed me out a PhD dissertation in which a researcher studied how relevant were individual contributors to open source projects when contrasted against paid developers. Google didn't help me at all to locate her thesis, but I remember that among the quoted accomplishments was the gathering of evidences in favor of the fact that most architecture-related changes submitted to OSS projects were perpetrated by paid people. I have some resistance to accept the supposition that X could live without the ongoing support of heavyweight companies for they usually hire the developers ultimately responsible for the design decisions which allow the software to evolve. For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 01 Jul 2010 16:15:58 -0300 Fernando Carrijo fcarr...@yahoo.com.br wrote: For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. I've wanted such a metric for a long time. Lines of code is a terrible metric for work done in general, even if you don't want to make a distinction between architectural and other changes. Changeset counts aren't really any better. Among other things, both create poor incentives if people actually start to care about the numbers. That said, I've still not found a better way of trying to measure who's doing the work, especially in the context of a high-bandwidth project like the kernel. If anybody has any ideas, I'm all ears... jon ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 1 Jul 2010 13:24:02 -0600, Jonathan Corbet cor...@lwn.net wrote:
On Thu, 01 Jul 2010 16:15:58 -0300
Fernando Carrijo fcarr...@yahoo.com.br wrote:
For sure the information contained in git logs don't measure how high-level
the
changes are being submitted, but it would be nice to devise some metrics,
apart
from the usual LOC, which could help us visualize the architectural impact
caused by the big players.
I've wanted such a metric for a long time. Lines of code is a terrible
metric for work done in general, even if you don't want to make a
distinction between architectural and other changes. Changeset
counts aren't really any better. Among other things, both create poor
incentives if people actually start to care about the numbers.
A viable solution would be to weight the hunks of a commit against a database of
scores for each file, or module, in a project. We could calibrate the database
by assigning higher scores to those files considered cornerstones, in lieu of
the less fundamental ones.
Thus, by maintaining a database such as the following:
FileScore
-
*.{xml,man,txt} 1
app/* 3
doc/* 2
driver/*.[ch] 3
xserver/dix/*.[ch] 5
xserver/hw/*.[ch] 4
we could run a script on a patch like this:
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
/* FIRST HUNK */
/* SECOND HUNK */
--- a/hw/xfree86/os-support/bus/Pci.c
+++ b/hw/xfree86/os-support/bus/Pci.c
/* THIRD HUNK */
and obtain a weighted score of 5 + 5 + 4 = 14 for the whole patch.
Here be dragons, though.
That said, I've still not found a better way of trying to measure
who's doing the work, especially in the context of a high-bandwidth
project like the kernel. If anybody has any ideas, I'm all ears...
Me too!
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 1 Jul 2010, Fernando Carrijo wrote: Tiago Vignatti tiago.vigna...@nokia.com wrote: If I have more motivation I'll try to get some stats comparing different versions of the server development and maybe other modules. Also, if you are interested on different kind of statistics I can run more. Suggestions are very welcome and appreciated (for instance fixing contributor - company)! A year or so ago, someone pointed me out a PhD dissertation in which a For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. most of changes being done are fixes, and do not contribute to structural changes in Xorg. i would be more interested in overall history graphs (since 3.3.6 release), with semantic analysis, MPX changes, etc. also note 'big players' usually implement same changes 'small players' do - which make software functional for their particular purpose, not nessesairly making development any easier for other cases. main difference is changes confidence factor. i've been silently following X development since at least 10 years, incl. vnc branches and i would surely hold out enthusiasm due to recent changes being made and planning outcomes from such short period of time recent stats did present. otoh i am very glad so many people still do contribute and maintain knowledge about code structure - imho this wishes the project at least next several years of existence. greetings and thanx to all for their great work through all those years. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 1 Jul 2010, Jonathan Corbet wrote: On Thu, 01 Jul 2010 16:15:58 -0300 Fernando Carrijo fcarr...@yahoo.com.br wrote: For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. I've wanted such a metric for a long time. Lines of code is a terrible metric for work done in general, even if you don't want to make a distinction between architectural and other changes. Changeset counts aren't really any better. Among other things, both create poor incentives if people actually start to care about the numbers. That said, I've still not found a better way of trying to measure who's doing the work, especially in the context of a high-bandwidth project like the kernel. If anybody has any ideas, I'm all ears... i doubt there is without engaging extra analytic workforce. i think while project will 'run' on it's own for several years, if anyone cares, separate semantic description and comment framework could be performed - altrough i doubt it can be done with such scarce resources like now - perhaps some university could be interested , but i again doubt it will be able to analyse such large project 'in spare time'. i certainly feel larger analytic brainstorm will be needed in course of next few years, and modularising X and code cleanup was major step forward it happening. though otoh when you look at 'bare numbers' of amount people interested in development there is serious doubt if project will be ever rebuilt , branched or sustained... there is still hope though at least major shortcomings will be spotted, and it will keep functionality and stability for next decade, even with even more shrinking interest and resources . greetings. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 05:47:59PM -0300, Fernando Carrijo wrote:
On Thu, 1 Jul 2010 13:24:02 -0600, Jonathan Corbet cor...@lwn.net wrote:
On Thu, 01 Jul 2010 16:15:58 -0300
Fernando Carrijo fcarr...@yahoo.com.br wrote:
For sure the information contained in git logs don't measure how
high-level the
changes are being submitted, but it would be nice to devise some metrics,
apart
from the usual LOC, which could help us visualize the architectural impact
caused by the big players.
I've wanted such a metric for a long time. Lines of code is a terrible
metric for work done in general, even if you don't want to make a
distinction between architectural and other changes. Changeset
counts aren't really any better. Among other things, both create poor
incentives if people actually start to care about the numbers.
A viable solution would be to weight the hunks of a commit against a database
of
scores for each file, or module, in a project. We could calibrate the database
by assigning higher scores to those files considered cornerstones, in lieu of
the less fundamental ones.
A patch that ends up being a single-liner may take a week to track down. A
patch that moves thousands of lines of code may be the result of an unifdef
run. Good luck finding some way to measure that ;)
Cheers,
Peter
Thus, by maintaining a database such as the following:
FileScore
-
*.{xml,man,txt} 1
app/* 3
doc/* 2
driver/*.[ch] 3
xserver/dix/*.[ch] 5
xserver/hw/*.[ch] 4
xkb/* INT_MAX
we could run a script on a patch like this:
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
/* FIRST HUNK */
/* SECOND HUNK */
--- a/hw/xfree86/os-support/bus/Pci.c
+++ b/hw/xfree86/os-support/bus/Pci.c
/* THIRD HUNK */
and obtain a weighted score of 5 + 5 + 4 = 14 for the whole patch.
Here be dragons, though.
That said, I've still not found a better way of trying to measure
who's doing the work, especially in the context of a high-bandwidth
project like the kernel. If anybody has any ideas, I'm all ears...
Me too!
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 09:40:50AM -0400, Keith Packard wrote: Not a huge number of changes this week; a couple of bug fixes, some server log cleanups and some Xephyr changes. Summary below, but first I've gone over the bugs in the 1.9 tracking bug: https://bugs.freedesktop.org/showdependencytree.cgi?id=27592hide_resolved=1 I'd like to encourage anyone with an interest to work on these and I think that from now until the release we shouldn't be merging any code which isn't tied to a specific bug. [...] o23938: keys occasionally get stuck with xorg-server 1.6.99.901 There have been a few keyboard fixes in the core server of late; any idea if this bug is fixed now? race condition, afaict still there though rather random to trigger. o23985: Excessive core motion events for subpixel motions This one doesn't appear to have been fixed, on the other hand, it doesn't look really bad -- clients just get too many events. feature request, not a blocker. problem since 1.7 anyway. o24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) I think this one could use re-testing. unlikely to be fixed, but I haven't tested since. some memory corruption, requires a specific keymap to trigger and time. o24856: xorg-server-1.7.1 mouse cursor not moving from MouseKeys This seems to happen only when not using SilkenMouse and/or SIGIO input. I have a vague memory of someone looking at this in the last couple of months? Pull request on list, consider this fixed. o25801: Switching VT re-enables XBell(), ignoring 'xset b off' Trivial to test, and I can't imagine it will be all that difficult to fix. I have yet to find a machine that actually rings a bell so testing is tricky for me. o27804: Enter/Leave event woes with multiple master devices. This one was posted by Peter, and surely looks to be solveable only by Peter. ++ out of cheese error, redo from start ++ None of the commented ones above is a new bug, we've put out 1.7 and 1.8 with them so IMO they are nice-to-fix but not a blocker. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
