On 01/06/2011 11:01 PM, Sven Neumann wrote:
> I just wanted to let you know that we have seen a dramatic increase in
> donations since then. More than 120 people donated over the last 8 days
> and sent us about 2,500 dollars. Perhaps it would be a good idea to
> discuss how we can actually use this money to make the GIMP 2.8 release
> happen soon...

Here are some examples of what I think blocks a GIMP 2.8 release:

  * Finish single-window mode
  * Make layer masks work with layer groups
  * Bug 596410 - gimp-image-get-filename returns NULL for imported files
  * Bug 597117 - impossible to drop a group as a sibling inside a group
  * Bug 612931 - Moving individual layer in layer group not possible
                 with Move Tool
  * Bug 600554 - Implement layer group transforms
  * Bug 624303 - Introduce an item class in PyGIMP
  * Bug 630748 - display filters do not work
  * Bug 631766 - Bad performance when moving brush outline on canvas

One natural use of money donated specifically to speed up a GIMP 2.8 
release would be in the form of bounties for fixing bugs that blocks 
GIMP 2.8 from being released. I know we have a history of disliking 
bounties, but as far as I know we never really tried, and now we have 
money more or less ear-marked for this purpose.

We must not put bounties on things with vague scope like "Finish 
single-window mode", that won't work. We can only put bounties on things 
where the work to be done is well-defined, like for

  * Bug 596410 - gimp-image-get-filename returns NULL for imported files

If the work to be done in order to get the bounty is unclear, we *will* 
get into problems.

I also think bounties shall only be claimable by people who would not do 
the work if there wasn't a bounty. For example, I won't and can't claim 
the bounty if I fix bug 596410, since I would have fixed it long ago if 
my spare time was infinite.

One tricky question is what the size of the bounty should be for each 
bug... Let's discuss that if we can agree on that we want to try 
bounties at all.

I think it is also worth to contemplate why we are in this situation 
where we want to make release, but can't because there's too much work 
left to do. The reason we are in this situation is because we develop 
features on the branch we make releases from. If things don't go as 
expected, like the case has been for single-window mode for example, we 
don't have any place to make releases from. The solution to this is of 
course to develop big features on feature branches. Basically, it should 
not be allowed to commit code to git master that is known to put the 
branch in an unreleasable state. We'll have good reasons to revisit this 
topic when we start working on GIMP 3.0...

  / Martin


My GIMP Blog:
"Nightly GIMP, GEGL, babl tarball builds"
Gimp-developer mailing list

Reply via email to