State of the Gtk+ Maintenance

From: Tim Janik <timj gtk org>

To: Gtk+ Developers <gtk-devel-list gnome org>

Cc: GNOME Foundation List <foundation-list gnome org>, Desktop Development <desktop-devel-list gnome org>, Gtk+ MList <gtk-list gnome org>

Subject: State of the Gtk+ Maintenance

Date: Tue, 19 Dec 2006 15:59:56 +0100 (CET)

Hello everyone. This is a statement about the current Gtk+ maintenance situation that I have recently been working on with lots of input kindly provided by Matthias Clasen, Mikael Hallendal and other folks at Imendio AB. Please note that this email has a Reply-To: header set for gtk-devel-list because it is cross-posted to a number of lists with tries to reach out to everyone likely to have an interest in the current and future prospects of the Gtk+ project and thus in the current maintenance situation. Gtk+ Maintenance Description ============================ This document describes the tasks that are involved with the maintenance of the Gtk+ project and outlines what could be improved by adding additional full time maintainer resources. Sections included herein: Description of Gtk+ Maintenance Tasks 1. Making regular and frequent releases 2. Communication tasks 3. General bug report handling and regressions 4. Refactoring and test suites 5. Optimizations and new features Concrete improvements by adding maintainers Remarks on Gtk+ project task assignments Description of Gtk+ Maintenance Tasks ------------------------------------- Gtk+ is a large free software project with a very complex code base and a large

user base with very different needs. The following tasks are involved in its

maintenance and ongoing development:

1. Making regular and frequent releases Making releases is a very large task for projects at the scale of Gtk+. A single release is usually multiple days of full time work because it consists of very time consuming tasks such as continuously adapting and fixing the build system, running the test suite and fixing the newly changed code and generating appropriate change lists out of hundreds of ChangeLog lines (often thousands). As a multiplying factor, this needs to be done for several packages, since often new versions of GLib, Pango and Gtk+ are released together. Also, at any given time, there are usually at least two branches which have to be maintained and released in parallel (for some periods three branches, since embedded platforms still stick to Gtk+-2.6), similar to the Linux kernel. The Gtk+ project has seen periods with too infrequent releases in the past, which imposed various problems in terms of users not receiving (security) bug fixes early enough, and as a side effect this produced many messy workarounds in third party code (which in turn tend to aggravate backwards compatibility constraints for the Gtk+ project). In particular the Gtk+-2.6 branch used on many embedded devices gets almost no attention from upstream these days. 2. Communication tasks It usually comes as a surprise upon reflection about how large the amount of time is an experienced maintainer has to spend on pure communication tasks. Especially with successful open source projects that have large user bases, many communication forums tend to evolve, such as large Bugzilla databases, IRC channels, web forums and mailing lists. Gtk+ makes no exception in that regard, and while the bigger part of such forums or mailing lists are specifically dedicated to non developer discussions, or development subjects that do not directly affect project maintenance, participation in the remaining core development forums is crucial and more often than not it greatly exceeds time spent on actual coding. However, naturally such exercises involve a lot of indirect programming work, such as analyzing Bugzilla traces and scenario descriptions, analyzing programming code and providing detailed reviews of patch or design submissions. What adds up to this is then a significant number of related forums that also need monitoring to some extend, for Gtk+ specifically these are for instance various Gnome core developer forums, the window manager specification list, usability list, accessibility list and others. 3. General bug report handling and regressions The more exposure a software project gets, the greater is the number of bugs that are reported against the code base. Due to the limited amount of maintenance resources available for Gtk+ over the years, the number of bugs has been steadily increasing, because the rate of incoming reports has most often been higher than the rate at which bug reports could be fixed and closed. Aside from producing a sometimes frustrating and unproductive atmosphere on the core developer and user sides of the project, this situation also tends to render outside submissions useless, because patches can become outdated before a core developer gets around to handle them, or because contributors fail to be available several years after a patch or report has been submitted. In some cases, such delayed bug reports concern hard regressions, where newer releases break established functionality and subsequent releases maintain the breakage. It is very important to have the required resources available to fix such regressions, in order to avoid putting long term investments from all involved parties at risk. However, if the shortage of maintenance resources denotes the standard, rather than the exception, the ability to remedy regressions adequately can not always be provided. 4. Refactoring and test suites Besides others, modern software development teaches us two crucial undertakings for long term (5-10 years and longer) software maintenance and sustainable development that Gtk+ in the past has notoriously been falling short on. These are refactoring and test coverage. With refactoring, even large code bases can be constantly reworked to stay robust and well deigned. Without it, there is no chance to remedy poor designs, and as code is changed it becomes more inefficient and increasingly harder to maintain. This goes hand in hand with test coverage. Changing old code in the absence of instantaneous feedback through test coverage is risky at best, and at worst the code contains more bugs than before. Gtk+ has not seen significant refactoring attempts after the release of 2.0 in 2002 and that is unlikely to change without a significant increase of investments into core development. Gtk+ also lacks proper automated test coverage in various areas such as the drawing primitive implementations in the various backends, thorough automated tests of container layout algorithms and stress testing of themable widget display and interaction. While some work is currently going on in a subset of these areas, the commitment here still must be vastly improved to reach a satisfying level of coverage, especially in areas that are partly still research topics like automated UI testing. 5. Optimizations and new features Important and sometimes crucial optimizations in terms of memory and CPU resource reduction had to be postponed or suspended, sometimes for years, due to lack of developer resources on the project. While the same can be said about some of the feature requests Gtk+ receives, the situation in general has been much better with features that could be split into or be identified as very specialized tasks in good isolation which could be implemented in an overseeable time frame. So on occasions, a contributor or company may turn up to undertake the implementation of e.g. a text widget, a rendering backend or platform port, or a file chooser dialog. Once this is integrated into stock Gtk+ however, the contributing party usually withdraws resources after some time and the code in question just adds up to the stock maintenance load of Gtk+. An aggravating fact for GDK backends is that the core maintainers often do not have access to the platforms these work on, so GDK backends generally fall into neglect, unless they have a dedicated maintainer working on the platform in question. Concrete improvements by adding maintainers ------------------------------------------- The Gtk+ project and any user of the toolkit will see a number of benefits from having one or more full time maintainers added to the project: * More regular and frequent releases: By having a shorter and guaranteed release cycles, new code will be available to the end user earlier. This means that: - New features will be on the market earlier. - Less changes between releases making it safer to stay up to date. - Test suites and build system gets more attention on regular bases. - More users of latest versions of Gtk+ meaning bug reports will be more up to date and target close in time releases. - The turn around time from bug report to fixed version is shortened. * Better communication: As described, a lot of time goes into communicating with the community, adding more resources to improve this situation, will benefit the project in the following ways: - Community relations will improve and allow more people to participate and provide feedback. - New developers will get more mentoring and faster get into the project. - Commercial vendors feel more confident in using the toolkit with better response times from the core team. * Better bug handling: There are currently a vast number of bug reports and patches lingering in the Bugzilla database. More people actively working through them ensures that: - More fixes will make their way into the upstream version. - Patches and bug reports will not rot in Bugzilla. - Contributing developers will not be left hanging while waiting for someone to find the time to look at their contributions. * More active hands on the source (refactoring and test suites): With more people actively and continuously working through the code base, the following areas can improve: - Code can be continuously refactored and improved to keep the code base maintainable. - Newly added test cases and results from these will get more attention and improve future code quality. - Optimizations of slow or wasteful code paths can be carried out more often and ensured to not break existing tests. - New features will have a shorter time to market. Remarks on Gtk+ project task assignments ---------------------------------------- New resources or man power requirements for the 5 categories listed: 1. Making regular and frequent releases 2. Communication tasks 3. General bug report handling and regressions 4. Refactoring and test suites 5. Optimizations and new features Can be split up and assigned according to experience level: * Active Contributor Areas where contributions can be made without much coding abilities: - assisting in release work, such as test building, running the test suite, compiling NEWS from ChangeLogs. - bug triage and verification. - communication, especially user forums and compiling FAQs. - language translations. * Inexperienced Developer Areas where contributions can be made with proper coding abilities: - assisting in release work, such as running and debugging items of the test suite. - eventually make stable branch maintenance releases. - communication in application developer forums, user forums and tutorials. - provide review of documentation, clarify and improve it. - help extend the test suite by writing new tests. - may be able to handle some regressions. - implement simpler features or simpler optimizations. * Experienced Developer Areas where contributions can be made with significant experience in the programming domain (GUI toolkits, X programming, familiar with some parts of Gtk+): - make releases, mentor release work. - communication, core developer forums and reference documentation. - can classify and comment/help on many bug reports. - help in extending and debugging the test suite and regressions. - refactor some of the code portions. - implement isolated or specialized features. - work on most optimization tasks. * Senior Gtk+ Developer Here, Gtk+ senior means someone who is familiar with most parts of the toolkit and library chain and normally is an experienced developer. He should be able to cover all of 1-5, and is required for all sorts of mentoring for the other developers and contributors. Depending on his background, it probably takes an experienced developer 2, 3, or more years of full time work on Gtk+ to become knowledgeable enough with the code base for being a Gtk+ senior. As outlined, pretty much everyone from the online community can help to some extend with the tasks described. We hope that more people make use of this opportunity in the future and thank everyone for taking the time to read through this document. --- ciaoTJ