[Gimp-developer] 2.6 roadmap: my summary.

[Raphaël Quinet]

On Thu, 22 Nov 2007 08:47:40 +0100, gg at catking.net wrote:
> I find it rather arrogant to presume that those who can code are the only  
> ones who can contribute to development and as a consequence anyone who can  
> code is also an authority on graphic design and UI implementation.

You are distorting what Sven said, but this seems to be a rather common
perception and complaint so maybe this deserves some clarifications:

Yes, the development of GIMP 2.6 will be mostly developer driven and
there will not be much room left for additional suggestions and other
stuff that is not already in the list of tasks that we are discussing
here.  I am not saying that to disappoint you.  I am saying that
because we have to cope with reality.

Here are some reasons:

- We have far more ideas than developers.  We even have far more *good*
  ideas than developers.

- The development cycle leading to GIMP 2.4 was much too long.  It took
  almost 3 years since the release of GIMP 2.2.  The development of
  GIMP 2.6 should be much shorter so that everybody can benefit from
  new features and other improvements without having to wait several
  years between stable releases.  But this means that we have to make
  some hard choices and leave some interesting stuff for later.

- The integration of GEGL and the support for higher bit depths is not
  a trivial task.  Although there were great hopes that GIMP 2.6 would
  have good support for 16 bits per color channel, fancy color spaces
  and other features that many users are waiting for, we will not be
  able to get all of that ready in time.  We will make some steps in
  the right direction, but there will still be a lot of work left for
  after 2.6.

So what does that mean?  We already know at this point that it will be
challenging to achieve all goals that are mentioned in the draft
roadmap for 2.6.  Some of these tasks may seem to be rather obscure and
may not bring many visible changes in GIMP 2.6, but they are necessary
so that the releases that will follow 2.6 can support higher bit depths
(in the core and in the plug-ins) and many other long-awaited features,
including some improvements in the user interface.

Considering that we are already struggling with the current list of
tasks for which some volunteers exist (there are developers willing to
spend some of their spare time working on them), I think that Sven is
right when he reminds you that it is not the right time to discuss
things that are not in the scope of 2.6 (tasks that are not already
supported by a volunteer developer).

-Raphaël