I’ve spent a lot of time recently getting some fairly ancient pieces of work pushed up stream, and it got me to thinking about how quickly we push new code upstream in the DRM, xf86-video-intel, Mesa and X server trees.
My primary interest lately has been the DRM tree, where two of the big features I’ve helped create took way too long (IMO) to land on actual user machines. So how have we done there?
|2.6.27..today||63||46 files changed, 7894 insertions, 2132 deletions|
|2.6.26..2.6.27||49||94 files changed, 58047 insertions, 0 deletions (tree moved to drivers/gpu)|
|2.6.25..2.6.26||38||29 files changed, 2937 insertions, 1335 deletions|
|2.6.24..2.6.25||47||63 files changed, 2721 insertions, 956 deletions|
|2.6.23..2.6.24||17||65 files changed, 2388 insertions, 3153 deletions|
|2.6.22..2.6.23||27||77 files changed, 2609 insertions, 2528 deletions|
Honestly, I expected to see more quantitative evidence of the qualitative changes we’ve made recently, but maybe that’ll take awhile to show up in the stats. The real issue though is the disparity in commits to the DRM tree vs. what got merged upstream: there were 1165 commits to the DRM tree in the timeframe above, including fairly infrequent libdrm changes, while the kernel only saw 241. At a high level that would seem to indicate that we did a pretty poor job of keeping the upstream kernel up-to-date, at least until recently.
For xf86-video-intel, I think things have been pretty good since we started doing quarterly releases. Our time based schedule means that users get new features and bug fixes in a fairly timely manner, though there occasional exceptions like feature trees that don’t get merged for a long time, if ever. For example the batchbuffer and kernel mode setting branches never got merged (though support for those features ended up in master anyway in different forms). We’ve been doing this for long enough that I don’t think commit stats would mean much (though it would be intresting to plot commit counts over time along with bugs reported and fixed I’m not going to do that today).
Mesa tends to see a lot of churn since it includes both the core 3D engine (and Gallium too these days) and all of the supporting drivers. Its release schedule isn’t as predictable as the kernel’s or xf86-video-intel though, which makes it hard to know when a given fix or feature will end up in the hands of users. AFAICT it operates on the “when it’s ready” release schedule, which is good and bad. Releases tend to be stable and long lived, but new features and fixes sometimes take awhile to get out. This is why for Intel we end up doing branched releases of Mesa every quarter so our latest driver fixes are available to distros and users right away. Any changes to the way Mesa works would probably need more developer time, which is fairly scarce in the open source graphics world, so I don’t expect this to change anytime soon. (I didn’t dig through the Mesa logs to see how things are here, so dear lazyweb etc.).)
What can one say for the X server itself? Let’s see how frequent those releases are:
|xorg-server-1_1_0||May 22, 2006||ajax|
|xorg-server-1.2.0||January 23, 2007||ajax|
|xorg-server-126.96.36.199||April 19, 2007||keithp|
|xorg-server-1.4||September 6, 2007||anholt|
|xorg-server-1.5.0||September 3, 2008||ajax|
Releases have been all over the place, from about a year apart to a few months, with correspondingly inconsistent release tags. I think this reflects both a lack of developer power and lack of clear ownership for the X server: no one person or organization “owns” the X server enough to make sure releases happen frequently, and getting people to fix server bugs for a given release is like herding cats, so release managers end up with the herculean task of doing everything themselves. Personally, I think pulling the drivers back into the server module would alleviate this somewhat, since it would give driver developers an interest in making sure the server is in good shape, and probably also induce them to work on server features and bugs so that releases could happen on a regular schedule. Very few people share this opinion though, so I’m not hopeful that people will agree to it anytime soon.
I’m hacking on getting the core DRM mode setting code ready for merge this week, along with the i915 code, but I’m not sure if my posts made the requirements for testing clear.
I posted a patchset for core, i915 and radeon mode setting to the dri-devel list recently, but there are a few other patches required in order to test those bits (which btw are very raw; I was able to get a root weave from X but things were pretty crashy if I tried to rmmod/insmod the module again). Anyway, if you want to live on the bleeding edge, you’ll need my xf86-video-intel EXA pixmap patch, and my libdrm & drm patches for GTT mapping.
Note that we don’t currently track per-pixmap tiling, so you may have to disable tiling in your xorg.conf to avoid corruption (either that or force every pixmap to be tiled in i830_exa.c at map or creation time).
|<< <||Current||> >>|