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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
