When I posted last week about evo and GNOME’s relative LoC and bugs, it was pointed out by at least three people that I used the wrong gtkhtml for the comparisons. Using the right gtkthml, evo/e-d-s/gtkhtml goes to 771K LoC(20.2% of all GNOME core LoC, including gtk), and up to 2379 bugs out of 10265 (23.2%). Enhancements are included in those numbers, so take them with an even greater grain of salt than usual.
Honestly, this all surprised me- I expected evo to be buggier per LoC than most of the rest of GNOME; it appears that this expectation was badly off. To be fair to my sense of things, things would have looked a little different a month or two ago- the evo guys have closed net over 400 bugs in the past month and a half, which is a pretty herculean effort.
For some comparisons with the same (weak) metrics, gtk+/glib is 13.2% of the code and 13.5% of the bugs. Nautilus+vfs is 4.9% of the code, but 11.1% of the open bugs. For nautilus/vfs, this is actually much better than it used to be; in the past year nautilus+vfs have closed net over 500 bugs, which is really impressive considering that this represents nearly 50% of the bugs that were open a year ago, and that a lot of those are the kinds of unpleasant, hard bugs that volunteers are supposed to hate, but that Martin, Manny, Christian and others are tackling effectively and with gusto.
I’d really like to be able to trend these types of numbers over time; bugzilla 2.20 should be slightly better than the current setup for this purpose when we’re able to upgrade. But getting the numbers right will take a while, as the bugzilla db layout makes getting such numbers very slow, unfortunately, and historical numbers have to be regenerated every time a new query is conjured up, which can apparently take days.
[LoC numbers were of course generated with the most awesome sloccount.]