My hypothesis is that the current system of hand-writing all bindings
is not sustainable, unless there were a dramatic influx of new
committers to this project. And even then, we would still have
long-term issues with API consistency.
Attached is a Python script which generates statistics that I believe
support this hypothesis.
The basic idea is to count the coverage per unit of time. I chose to
use a week. Here's sample output from my script:
offset: -0 revnum: 455 methods: 1010
offset: -1 revnum: 453 methods: 1010
offset: -3 revnum: 450 methods: 1010
offset: -5 revnum: 444 methods: 990
offset: -6 revnum: 433 methods: 974
offset: -7 revnum: 429 methods: 970
offset: -8 revnum: 421 methods: 935
offset: -9 revnum: 410 methods: 914
offset: -10 revnum: 404 methods: 861
offset: -14 revnum: 403 methods: 861
offset: -15 revnum: 399 methods: 860
offset: -16 revnum: 395 methods: 691
offset: -17 revnum: 371 methods: 663
offset: -18 revnum: 355 methods: 558
offset: -19 revnum: 352 methods: 513
offset: -21 revnum: 351 methods: 512
The "offset" is the number of weeks ago, "revnum" corresponds to the
BZR revision number from mainline, and "methods" is the number of
implemented methods, as adapted from src/utils/coverage.pl.
We can see in this graph that progress has been pretty jumpy; in the
last few weeks the coverage has not increased at all. I don't have
the precise number handy, but from an observation it looks like the
project is perhaps adding 30 methods/week, tops. According to the
hardcoded number in coverage.pl, there are 5468 methods to implement,
and currently we have 1010.
Using that conservatively-high rate of 30 methods/week, hand-writing
4358 bindings will take 145 weeks. That's 2.7 *years*. But even that
is probably overly optimistic, because some parts of the API are much
harder to bind than others.
I've attached the full output from my script, as well as the script
itself. You can regenerate the results like this:
python coverage-revisions.py /path/to/java-gnome
|
