Releases in graphics land

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.

DRM

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?

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.

xf86-video-intel

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

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.).)

X server

What can one say for the X server itself? Let’s see how frequent those releases are:

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.

6 comments • Trackback (0)

Comments:

Comment from: Donnie Berkholz [Visitor] · http://dberkholz.wordpress.com

My rather strong opinion is that people should only work on the things they want to work on. Being forced to do anything else hurts their overall motivation and results in less effort going into even their core interests.

Permalink 11/10/08 @ 14:26

Comment from: Michel Dänzer [Visitor]

Dave Airlie would often combine several drm Git commits (e.g. the initial implementation of a feature and subsequent bugfixes) into one for merging to the kernel, so the difference in the commit numbers doesn't necessarily support your conclusion.

Permalink 11/11/08 @ 00:49

Comment from: Michel Dänzer [Visitor]

Oh, and drm Git has things like the nouveau driver which are intentionally not in the kernel yet.

Permalink 11/11/08 @ 00:57

Comment from: ethana2 [Visitor]

Hopefully Wayland has a better release schedule than X...

Permalink 11/11/08 @ 12:38

Comment from: jbarnes [Member]

Re Michel's comment, yeah that's true, the DRM tree merge process is more complicated than a simple set of commits going from one tree to another. So the commit numbers themselves don't justify the conclusion I had already drawn on a qualitative basis. Certainly everyone is entitled to an opinion, but it seems clear to me that the old DRM process was failing pretty badly at getting bits into distros and into users' hands. Of course, not everyone measures success that way, since delivery mechanisms for the DRM code vary depending on who you are (if you're a contractor there are totally different issues at play for example), but for an IHV like Intel trying to get code out into the distros and shipped in a timely manner it was pretty bad.

Permalink 01/05/09 @ 17:09

Comment from: jbarnes [Member]

Donnie, I totally agree. I never understand discussions about what people should be working on out in the community mailing lists. Unless someone is actively asking for guidance, it's silly to say "this or that needs to be done" unless you're willing to step up and do it yourself. I think that's why release management often sucks in open source projects. The job is no fun and not many people have a personal interest in it. That said, different organizations definitely do; Red Hat, Novell, Gentoo, etc, probably don't want to maintain huge forks of an upstream codebase, and IHVs like Intel don't want to duplicate work for every distro, so there are some pressures to make sure upstream releases are smooth.

Permalink 01/05/09 @ 17:14

Leave a comment:

Name:

Email:

Your email address will not be displayed on this site.

Site/Url:

Your URL will be displayed.

Comment text:

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>

Options:

Auto-BR (Line breaks become <br />)
Remember me (Set cookies for name, email and url)
Allow message form (Allow users to contact you through a message form (your email will NOT be displayed.))

Captcha:

Please enter the characters from the image above. (case insensitive)

Captcha code:

Trackback address for this post:

Captcha:

Please enter the characters from the image above. (case insensitive)

Captcha code:

Trackbacks:

No Trackbacks for this post yet...

Pingbacks:

No Pingbacks for this post yet...