Hacking:GIMPCon 2003, Berlin, Germany, 2003

From GIMP Developer Wiki
Jump to: navigation, search

The second GIMP developers conference took place the 7/8/9/10th August 2003 at the Chaos Communication Camp. The Camp was an international, four-day open-air event for hackers and associated life-forms on a field near Berlin, Germany. The GIMP developers joined this event and set up a GIMP tent to get together and discuss the future of GIMP development. Three big meetings were held at GIMPCon 2003. The topics of these meetings are listed below along with links to the minutes of the meetings.


The People at GimpCon 2003


The First Big Serious Meeting

August 7th 2003, around 8pm

Written by Dave Neary

Discussion was led by Daniel Rogers (dsrogers) but stuff said is for the most part anonymous. Partly because there shouldn't be any ad hominem attacks that way, and partly because I didn't take down any names.

Present: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary (bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis), Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin Williamson (calvin), Roman Joost (romanofski).

Absent but at camp: Maurits Rijk (Maurits), Branko Collin (bbc).

Topic discussion, in approximate chronological order:

The GIMP Foundation

The idea of a foundation was proposed. Lots of ideas were thrown about as to what kind of remit it would have. If created, the foundation would certainly have 2 things we don't have at the moment - a bank account people could donate to, and a focus on “marketing” in the broadest sense of the word.

Some of the issues were whether the foundation would be set up in Europe or in the US (in the US it might make it easier to get donations from US companies, but in Europe we're not as litigious, so setting up would certainly cost less, but then we probably wouldn't have NPO status in the US), whether it would have any technical aspect (that is, would the foundation act as a kind of steering committee for the general direction of the GIMP?), and how, if the issue came up, we might pay someone.

This led onto a discussion of whether the foundation would be responsible for setting release dates, or whether we would have a separate...

Release Manager

The general consensus (more on that later) was that a release manager is a good thing. There do seem to be a few different ideas of what the role would entail. The general idea would be that the release manager would be responsible for following CVS and know at what stage a given feature is at, follow bugzilla making sure that bugs got milestoned for some release in order of their priority, would annoy people to get commits in before feature freeze dates or postpone mercilessly features which are not finished.

It was agreed that a release schedule would be helpful to define the perimeters of responsibility of the release manager - basically, some way to set up large milestones to aim for with things to go into those milestones. This release schedule would be subject to revision, and would be no more realistic than any other release schedule, but it would serve as a guide for development. Dan agreed to draw up a first draft of this, and we'll have something more concrete before the end of the weekend.

The questions that came up about the release manager were things like where his authority comes from, how does he decide which bugs are important and which features can be postponed and so on. In other words, how do decisions get made. Is the release manager a benevolent dictator, or does he answer to the larger developer and user community? If so, to what extent? Is backing out CVS commits OK, for example?

So we started talking about how to get contentious decisions made.

Decision making (or lack of it)

Currently, there are two ways to get something done in the GIMP. First, you can write decent code and patches for a while, until you get CVS commit access, then you write whatever feature you're interested in, and commit it. If no-one backs it out, then it's in.

Second, you can bring it up on the mailing list, or in bugzilla, or in IRC (more on communication later), and discuss it until there is a consensus. However, we tend to be pretty bad at reaching consensus on anything even slightly contentious. The important questions to be answered any time a discussion like this comes up are what's going to be done, and who's going to do it.

It was agreed that beyond a certain point, there is generally very little technical merit to these types of discussions. It was felt that about 5 days was enough for everyone with an opinion on a given matter to make that opinion known, and that after that point, it would be an idea to have a summary of the salient points and close the discussion. That means, the people here would stop posting to the discussion. Of course, if other people want to keep on flaming, they're free to do so, but people will just ignore the thread.

At this point, the summary should sum up the various points, and finish with an answer to those two questions - what gets done, and who's doing it.

We may even have a bake-off system. If there are two competing ideas for the way something should be done, currently no-one tends to do it. Ideally, both people would do it and we pick the best one.

This brings up another point, though - in general, what is authority? And in particular, at what point has someone gained enough standing and authority to post one of these thread-ending summaries? Some discussion is going to be had on that over the weekend.

General stuff, about Bugzilla and CVS

We talked about various ways of improving the way we use these tools. First is whether it makes sense for us to have module owners, and if so, who should they be? Should we use the system of bug owners to track who is responsible for a bug at any given time, or is the current scheme of bugs@gimp.org sufficient? Do we need to change bugs@gimp.org to something else to avoid confusion with the old bug reporting address? There were a few open points in here.

Second, we talked about pre-release branches, and whether it would be worthwhile having a mozilla style release cycle with feature-freezes, followed by concurrent bug-fixing before unstable releases, freeing up the branch for bigger stuff that people want to start committing. In general, it was felt that there was very little to be gained from that, and the current system of a long-lived devel branch with self-imposed feature freezes every few weeks was a better way to go.

We also expressed a desire to have more redundancy in the non-technical aspects of The GIMP, things like the mailing lists and ftp mirror lists should have more than one person with the ability to change them so that if there's a problem, and that person has no time to take care of it, then someone will. Perhaps using a Debian or GNU style ticket system might help here fro these particular tasks? In any case, everyone in a given group should know everyone else in the group, and know more or less that when an issue gets in, it will be handled by at least one person.

Communication

It was agreed that we need to communicate better (that's a no-brainer, really). For a start, every developer should be subscribed to the userlist. gimp-devel (if it doesn't disappear altogether) would only be used for technical discussions of implementation details - all the philosophical level discussions of new features, ui changes, release mechanisms and so on should be discussed on the user list.

Basically, we're going to talk a lot more about how the developers can interface better with the users.

Decisions

Not too many of these... we will have a release manager, but we need to define exactly what his/her remit will be. And who it will be. We agreed that the “5 days and it's dead” rule for threads makes sense, so that will be done.

Future

  1. Roadmap - rough release schedule, we will have a first draft today.
  2. GIMP Foundation - we need to define its responsibilities, set up election rules, and get this set up. The principle of the foundation is more or less agreed.
  3. Communication
  4. Release Manager - what'll he do, who'll he be. This should be short once we have discussed communication channels a bit.
  5. Technie stuff - Sven and mitch are going to talk to us about the re-organisation of the code, GObjectification of everything, and other stuff. Daniel and Calvin are going to talk to us about GEGL and how they feel The GIMP could use it. This will probably be a two-way discussion about what kind of things we expect GEGL to furnish as well.
  6. GIMP tutorials - jimmac and nomis are going to do some presentations for people, which should be good.
  7. Plug-in distribution - 3 years ago this was discussion, yosh has been working on something as a proof-of-concept, it would be nice to address this and get something in place soon.


The Second Big Serious Meeting of GIMPCon2003

August 8th 2003, around 8pm

Written by Dave Neary

Discussion was led by Daniel Rogers (dsrogers) but stuff said is for the most part anonymous. Partly because there shouldn't be any ad hominem attacks that way, and partly because I didn't take down any names.

Present: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary (bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis), Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin Williamson (calvin), Roman Joost (romanofski), Maurits Rijk (Maurits), Branko Collin (bbc).

Topic discussion, in approximate chronological order:

Features required for 2.0

There was quite a lot of talk on what was required for a 2.0 release. It was agreed that a pre-release should have feature complete versions of everything going into 2.0, for obvious reasons. These can be somewhat buggy, but they should at least support what is supported in the 1.2 equivalents.

The major features or API changes which it was agreed are necessary are:

  1. Complete path tool (nomis)
  2. Remove libgck (Sven and mitch)
  3. Finish the text tool (Sven)
  4. Documentation (more on this later)
  5. Web-site (again, more on this later)
  6. Some libgimp changes which need to be made now so that we can havebinary compatibility across a 2.2 release

Documentation

We felt that with pre-releases, the documentation will become more complete. There should, however, be an effort to actively get people writing docs. The main requirement, then, for 2.0 pre-releases will be to have a working help framework, so that when people hit F1 for help, they at least get a message saying “This help item does not exist yet.If you would like to help write it, contact docs@gimp.org” or some such. [1]

If documentation is going to be released as a separate package, as now seems likely, then we will need to define the interface between the core and the help pages reasonably quickly. The general idea is to more or less hard-code tagnames for a particular help topic, and get the core and help using the same tags, and agreeing on how they be communicated. This will presumably require a considerable amount of communication with the help team.

We also need to have the docs browsable online so that if people want to browse them they can.

Web-site

The new site should switch over to www.gimp.org soon. There will obviously be quite a bit of pain involved as content gets added and we get lots of “your website sucks” type feedback, but this will only befor the short term. We should switch to mmaybe as the main site before 2.0pre1. It was suggested to do it even earlier than that, in the region of 2 to 3 weeks time.

It was also discussed whether it was a good idea to have a separate coordinator for the website.

Roadmap

As an approximate set of ideals, it was agreed that we want this: 2.0pre1 very soon, 2.0 soon, 2.2 next year, and GEGL integration the end of next Summer.

More specifically, the near-term release schedule that we agreed was reasonable is this:

1 or 2 developer releases (one now, more or less, and another one in another 2 weeks). 6 weeks time (end of September 2003): First pre-release of 2.0, including the features mentioned above, and any other minor features that people code in the meantime (hint, hint). Roughly 3 months later: 2.0

It was more or less agreed that 3 to 4 weeks was a nice turnaround time for pre-releases, so that would imply between 4 and 6 (inclusive) pre-releases before 2.0.

The reason for not having a pre-release straight away was mentioned above: to be feature complete, some features need a little more than 2 weeks work, and people have real lives. So 6 weeks was felt to be a reasonable amount of time to have the path tool and the help browser in place.

Bugs

The developer release will also be a prelude to a bug week. We would like people (that's you, in particular) to actively work on bugzilla clean-up for 2.0 - bugs need to be prioritized, unconfirmed bugs need confirming and milestoning (and if you're feeling really helpful, fixing). The idea would more or less be that the 2.0 milestone will be locked down for anything other than serious bugs after this bug week, so if there are bugs that are annoying you a lot, this is your chance to get them considered and worked on for the 2.0 releases.

Just to spell that out - at the end of the bug week, any bugs reported against The GIMP in CVS will be milestoned for 2.0.x, or even 2.2, unless they are considered blockers for the release. If we want to get a 2.0 release soon, we need to get lots of testing done, and lots of bugfixing done, but we also need to choose what to do and what not to do. We felt this was a reasonable compromise.

It was also re-discussed whether it would make sense to have module owners. The conclusion was that for certain components, it makes sense to have a smaller group of people getting the bug reports and having responsibility for them. This would be done via mail aliases for the group of people guiding the component, in a similar way to that which is used for (say) gtktreeview in gtk+.

The module owner group wouldn't have to be technical, and we should be actively recruiting people to do this kind of work and leave more time for programmers to program.

This leads us on to...

Task list

There are lots of non-technical jobs that need doing around the gimp-docs, website, bugzilla triage, internationalisation, etc. Often it is quite difficult to know what needs doing, and who to contact about getting it done. We need a list of bite-sized tasks that people can do, including the kinds of tasks that only take a few hours a week to do, but are ongoing tasks.

We used to have a TODO, and we could use that system again, if someone were maintaining it. That could come under the remit of the release manager to some extent, but since the mainenance of the TODO list is mostly a non-technical task, anyone could do it (in fact, as an example of a task, “Maintaining the TODO list” would go in the TODO list).

We might do this through Bugzilla using a keyword to allow getting at the list easily, which would imply getting more people looking at bugzilla regularly. Then again, if there were a link to a bugzilla query on the webpage marked “GIMP TODO list” we could get that for free.

GIMP Foundation

Basically, we're agreed this is a good idea to have some kind of public face people and companies can contribute to. There is no problem with having 2 foundations, one in Europe and one in the US. It was more or less agreed that assigning copyright to the foundation isn't going to happen soon (for a start, so many plug-in authors have gone their merry way and are almost unfindable) This may hapen in the future, but most people felt that it would not be something they'd be happy doing personally.

Other people said they would prefer to assign copyright to an organism under the jurisdiction of European law rather than under US jurisdiction.

So, to sum up, there's no reason not to have one of these. Daniel Rogers has agreed to do the necessary paperwork and set up the foundation and the bank account for donations in the US. Pretty quickly after getting that up and going, we will need to get a board of directors and a set of by-laws. We know lots of people who can help with this (in particular, the GNOME foundation and the FSF).

If someone wants to set up an equivalent in Europe, we're all ears. Currently no-one has said they'll do it, so it's an open point. To start, the foundation will only be a board an a bank account - in the future, we could expand its responsibilities to promotional work, a single point where people could go to get speakers, a group that does press releases and so on. It was agreed that at least in the short term it is undesirable to have the foundation have actual control of source code, just in case the foundation then gets sued.

In brief, it's being set up with a very narrow remit, with the possibility to expand later if it is felt that there is a need.

Release manager

The responsibilities are:

  • Follow CVS so that he can write release notes, and knows at any given time who is working on what, and at what stage it is
  • Follow bugzilla closely
  • Make releases regularly, according to the roadmap (or make sure releases get made)
  • Update the roadmap to reflect reality
  • Write release notes for the releases (keep NEWS up to date)
  • Generally annoy people sending mails to the mailing lists and sending content to the website to explain the state of play and get people to work on stuff.

Dave Neary (me) agreed to do this. He already regrets it.

That's it folks - today, Sven and mitch are going to talk to us about the major changes in the codebase and the general utility stuff which exists now which has been written from scratch, Calvin and Daniel are going to talk about GEGL and how we can use it, and work towards having a GEGL that we can use in a year. I'm going to lead a discussion on communication in the GIMP, and how to maybe make it easier for people to contribute, and jimmac is going to demonstrate what a power user really is.

Goodbye from everyone at camp. As usual, comments are welcome on all this stuff. While on a philosophical level, we are agreed on the direction things should take, all the details are open to discussion, if there's any reason to change them.


The Third Big Serious Meeting of GIMPCon 2003

August 9th 2003, some time in the afternoon

Written by Raphaël Quinet

Here are the minutes of Yet Another Big Meeting that took place this afternoon in the GimpTent. The meeting was chaired by Dave Neary and these minutes were written by Raphaël Quinet.

The title of this meeting was “Communication”. The main topics were how to improve the communication between developers and users or potential new developers. We also discussed how to present The GIMP to the “outside” and how to make it easier for new users to try out The GIMP or get involved in GIMP development.

Altough there was no pre-defined agenda for this meeting, the following topics were discussed:

How to get new developers?

Like in any Free Software project, developers are leaving from time to time to pursue other projects. And from time to time, new developersare joining the team and starting to contribute. However, it looks like the number of new developers joining the GIMP development has been decreasing in the recent years. This may be due in part to the fact that there haven't been any major changes in a stable release for a long time.

Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it ismore difficult to have a working build environment for the 1.3.x version. This problem may be solved as time passes, because more and more distributions will include the required libraries.

There should be a section on www.gimp.org or developer.gimp.org titled “How to contribute?” or “How to get involved?”. It should be easy for potential new developers to see where to start and how they can help. More on that below.

Do we need binary distributions?

There was a discussion about binary distributions. This may help people to try some versions of the GIMP (especially the development versions) without having to compile everything. However, maintaining binaries is a lot of work, even if we only maintain binaries supplied by others. In addition, this would bring some additional responsabilities that we do not want to have. For these reasons, it was decided that www.gimp.org would not host any binaries but would link to the pages of those who are providing binaries for various platforms.

It would be very nice to have Windows binaries for the development version.

Is Bugzilla too hard to use for new users?

It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known). This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does nothave a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes.

Most developers consider Bugzilla to be a very valuable tool that works well. Instead of trying to hide Bugzilla from the users, we should try to make it as easy as possible for the new users to join. This is already done to some extent by the bug submission wizard available from http://bugs.gimp.org/. There is a small problem with the GNOME2 keyword that prevents the open GIMP bugs from being displayed to the user and we should try to get this fixed.

List of open tasks

There are many open bug reports or proposals for enhancements that would be relatively easy to fix or implement. We should make it easier for potential contributors to see the list of easy tasks that are open. The “easy tasks” should include anything that can be done in one or two hours by an average developer or maybe a bit more if the contributor is not familiar with the code.

The best way to keep the list of open tasks up-to-date is probably to base it on Bugzilla. We could for example use a Bugzilla keyword for all bugs that are easy to fix (there is already a keyword “easy-fix” reserved for that, although we could invent our own). It would then be easy to create a Bugzilla query showing the list of easy tasks. Another solution would be to have a page on www.gimp.org or developer.gimp.org containing a list of all these bugs, with direct links to the corresponding bug reports. The second solution may require a bit more work because it would have to be maintained by someone, but it might be a bit easier to use.

Mailing lists

Sometimes, there is a lack of communication between users and developers of The GIMP. After some discussion, it was decided that we should not merge the mailing lists gimp-user and gimp-developer because this could cause various problems: the combined amount of traffic may be too high for some subscribers, the discussions among developers may be confusing for some users, and in general we should let people subscribe to what they are interested in, instead of removing this option by merging the lists (we cannot force anybody to read what they do not want to read).

But it would be very useful for the developers to get more feedback from the users, especially about UI and usability issues. For this reason, all developers are strongly encouraged to subscribe to the gimp-user list.

The web site (www.gimp.org) should contain a list of the various sources of information about the GIMP: mailing lists, newsgroup, Yahoo group, GUG, other web sites such as linuxgraphic.org or gimp.de, etc. The description of the mailing lists should encourage people to subscribe to both the users and developers lists.

Summary

We hope that the next stable release will attract new developers. This has been the case when 1.0 and 1.2 were released. The transition to the new web site will also help, especially if the navigation menu contains some useful items such as “Bugs”, “FAQ”, etc. The following items should be available in the web site:

  • “How to contribute?” or “Getting involved”
  • List of tasks
  • List of sources of information (mailing lists, newsgroup, ...)
  • FAQ

As with the other documents summarizing what is happening here at GimpCon, comments are welcome...

Sponsors

We'd like to thank the Free Software Foundation, O'Reilly Germany, MacGIMP, FlamingText and the Chaos Computer Club. Without their support this meeting wouldn't have been possible.


  1. That email address doesn't exist (yet). People interested in helping with the documentation should have a look at the Wiki.