Apr 252007

Gtk+ Patch Testing & Committing:
Recently i was caught on IRC and asked to look into a few outstanding Gtk+ bug reports. Some of them easy, some of them not so easy, e.g. one required a lengthy in-depth evaluation of interacting code while some of the others already had patches applied. That particular moment, I barely had any spare time to look into Gtk+ bugs and was actually on my way to the shower and then head downtown. We still managed to squeeze in and close the bunch of 3 or 4 bug reports in less than an hour however, because people actually helped me in applying, compiling, testing and committing the changes. While core maintainer approval was a necessity for some resolutions, there was much more work to be put into each report beyond giving the OK to the final patch versions. In particular the patch applying, adaptions to recent trunk, compiling it, running the test suite or test cases and committing is something that many developers who are not overly familiar with the code base can still do. This is a great way to learn and get into a project, and to help out an understaffed core team. It is a great way to contribute to your pet project and will help to make your visions and ideas about it come true.

You can do this for Gtk+: Patch testing & committing

Gtk+ has a volunteer task list up on the wiki. One of the open positions is the one i just described, and it’d much help the project if people signed up for it. Note that having SVN access can help but is not a requirement for all tasks, access rights can be granted for active contributors.

Next time you wonder why your Gtk+ bug report seems stalled, don’t ask why it’s being processed so slowly, ask yourself why you’re not helping the project already, so all submissions can be processed faster, including yours. 😉

  2 Responses to “25.04.2007 Call For Help”

  1. Would it possible (or desirable) to add the checklist you describe as a series of states within bugzilla for bug reports with outstanding patches?

  2. Well, the individual tasks i described in my blog are still a simplification to an extend. E.g. they are not necessarily always carried out in that order, or tests might need to be run with a specific focus in a specific environment, the patch gets adapted and then the whole thing starts over, etc.
    That doesn’t naturally lend itself to Bugzilla states, but usually most of these steps are at least recorded as seperate Bugzilla comments.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>