State of the Gtk+ Maintenance

[Tim Janik <timj gtk org>]

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