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:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
