How bad were GNOME’s CVS build problems during 2.16.x?

GNOME CVS is supposed to be buildable and dogfoodable at all times. Those who were watching during the last release probably noticed that it was rarely true during that cycle. Lots of people pointed it out, and I argued a number of times that the problems were driving away potential contributors and cutting too much into developer time. I was surprised today to find that I didn’t quite have it right. It didn’t just cut into developer time, there was at least one case where module maintainers were prevented from working on their module! That sucks.

I hope that the new external dependencies handling fixes much of this. I wish I had more time to push things in this area to improve things further, but I’m handling all I can with various release-team tasks right now (also, sorry Carlo for not getting to your metacity patches yet…). I’m glad we have Frederic Peters around kicking butt by constantly monitoring for build problems and filing bugs and alerting people when issues come up. The Build Brigade also excites me; some great work has been done and if they can accomplish even a fraction of the listed tasks then things will improve a lot.

6 Responses to “How bad were GNOME’s CVS build problems during 2.16.x?”

  1. Tom says:

    At one point while

  2. Tom says:

    At one point while I was still in college, I made a serious attempt to become a GNOME developer (probably around GNOME 2.6 or 2.8). I had quite a bit of programming experience, but I didn’t have much experience with a autoconf. automake, libtool, etc. I was using jhbuild to try to get a CVS version up and running. Over the course of a couple of months, I tried to build GNOME every couple of days — and it was almost never buildable. Sometimes you could find information about what happened on the mailing lists, but the solution was usually just to wait until that particular package was fixed. I remember that gstreamer was going through heavy changes at the time and was almost always broken. Basically, I never figured out how a person was supposed to help develop GNOME. If you skip certain packages, then how reliable is that build? If you can’t get a version working from source, how can you test for repeatability of bugs filed in bugzilla? How can you test any modifications? How do the GNOME develops actually work? Eventually I decided that there were better uses of my time then spending hour after hour trying to figure out why some package all of the sudden won’t build.

  3. Tom says:

    s/GNOME develops/GNOME developers/
    s/time then/time than/

  4. Fry says:

    When I want to hack on something, I usually get the ubuntu package, its build dependencies, and build it into a custom prefix. Then if I have been productive enough to get a patch I get the CVS module, build that (ubuntu dependencies are usually OK), and re-apply the patch there.

  5. Rambokid says:

    here’s more evidence for module maintainers being prevented from hacking on their stuff. i’m unable to build gnome up to libgnomecanvas (for which i’m about the only maintainer at this point) for more than a year on my desktop machine now. that’s due to dbus segfaulting when being called for code generation during build of the dbus module. this problem has repeatedly been reported to the dbus maintainers, but all the last emails on the topic simply got silently ignored.

  6. Agree 100%! But, disregarding some issues with gnome-doc-utils, GNOME has been very buildable with jhbuild lately. And solutions to most problems can be found from http://live.gnome.org/JhbuildIssues. Ofcourse, this is all thanks to the hard work of hundreds of GNOME developers and testers. Non the less, I’m pretty sure GNOME is much, MUCH more jhbuildable now than it has ever been before.