On Fri, Jan 7, 2011 at 1:27 AM, Martin Nordholts <ense...@gmail.com> wrote: > 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. While this will work for clean-cut and simple bugs, this really isnt where we are hurting most now.
Here is the list of things where we I think are really really hurting: * GTK2 tablet support is totally busted. Mitch is fixing GTK3, but releasing now would mean crippled tablet support all around. 2.6 people can downgrade, we cant. *GUI specs are declared a blocker for anything, but there are none, so even if I have time for coding I'm not allowed to do it. Peter is working on this by looking interns. But this is pretty much the reason that only one doing any serious work is Mitch... * *This bit is important* Nobody to implement Peters glorious specs. I can't, because most of them don't just require using GTK, but writing widgets en masse, Martin and Sven are busy with life, mitch is fixing GTK3... There is nobody on the team with those skills and the time required so any specs that do get written just generate frustration. * SWM and the fact, that nobody has been working on it for a year is also caused by two points above. Long story short, we need another GTK person on the team. One that CAN write widgets and as a paid employee cant just wander off when Peter tells him to do something he doesn't like. > 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. I agree to this. > 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... But not with this. Having a summary dirty development branch is very important. If it has to be the same as releases branch, can be debated. But without continuous integration agile development does not work. You end yup with a handful of forks that don't fit together. Anything left in the isolated branches too long will suffer bit rot. But git offers interesting options. Perhaps theres a way to have the cake and eat it too. -- --Alexia _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
