Hi list, Hereafter, I'll try to share with you some of my views and thoughts about f-spot and his development. I really do not want to hurt anybody nor pointing anybody. I'm aware that F-Spot is mainly made from volunteer and I'd like to thanks each of them personally (and btw, my house is always open and there's beer in the fridge, you're all welcomed !). Once again, these are my views, and I'll be pleased to discuss them with you, maintainers, developers, beloved users. Everything is only proposal, and I'll be happy to listen to yours.
* Goals, milestones and enhancement acceptance ============================================== I know that the big goal of F-Spot is to rules the world or be THE photo manager for my mother AND the semi-pro photographer, but how can we achieve this ? Let's see first how F-Spot development works those days (or appears to work, viewed from my desk)(I do not speak here about bugs, only new features): - Peoples submit ideas or needs, mainly on b.g.o. about things missing or things to enhance in F-Spot. - Some of those bugs are completed with a patch, either by the original author or by another developer - Some of those patches are reviewed - Some patches, reviewed or not are committed by the CoreDevelopers in CVS HEAD. - Some brand new code (without enhancement request or review) also ends up in CVS HEAD What's wrong here, how to improve that? - Some enhancement requests will never be filled. Mainly because the request is way too far of the F-Spot goal, or aimed to fill a need for only a minority (the bug reporter). Those requests needs to be closed by the CoreDevelopers early or after a small discussion. There's 10th of bugs like this in b.g.o. Don't let the developers waste time proposing patches that will never reach CVS HEAD. - Some enhancement requests are pretty cool. Fix this as a GOAL to achieve. Even if there's no patch to fulfill the request. - Some brand new code ends up in CVS. This means two things to me: 1) the CoreDevelopers have plans about how to gear F-Spot up. If such plans exists, let's share them and involve other developers 2) Some code reach CVS without sufficient reviewing. Sometimes (but it's very rare), the same code proposed first in b.g.o. will never reach CVS as-is. And finally: - Patches needs review !!! There's not a lot of big patches to review, and apparently we are something like 10 guys spending some hours every weeks in the F-Spot code. If all developers could spend 1 hour a week to test and review ONE patch, all patches in b.g.o. will have at least 2 reviews before the end of September (I don't speak about one-line bug fix). How to make it rocks ! - the CoreDevelopers had to define goals. It's already done with the ToDo, Specs, UseCases and NewFeatures on the website. - aggregate goals into milestones, and try to focus the developers to achieve this milestone. An example of milestone could be 'Focus on Export' with 314559 335935 321298 336161 345123 329685 336178 345098 as goals... - and, as all of this is quite a big job, extend the CoreDevelopers a little bit (CVS write access, weekly IRC meeting, ...) * Keeping the bug count low =========================== What about the other bugs, the real ones, the annoying ones (not the enhancement) ? - Fix them. - Fix them quick ! - Submit in CVS - Close the bug. There's more than 10 patches that fixes bugs with one or 2 lines of code ! Those one or 2 liners probably don't need to be discussed and reviewed and everything. But they need to be fixed in HEAD! Take care of the users, waste 20 minute of your morning time to reply to one new bug reported in b.g.o. Most of the time, it's well rewarded and helps having a good day at work. And what about fixing a meta-goal ? like reducing the bug count to less than 200 for the end of the year (or quicker) ??? * Release early, release soon ============================= (http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html) I'm not speaking here about *real* release. Official releases need to be well polished and almost bugfree because it's targeted to the largest audience. No, I'm speaking about the patch acceptance speed. If a patch is good enough and if the feature request is reasonable and accepted (see upper), commit it to the CVS HEAD. this will de-facto increase the number of testers and probably reduce the time to the feature completion (opposed to the same patch living in bugzilla, reviewed, commented, modified, ...) * Have fun ========== Last but not least, only do this because it's fun ! and useful. Enjoy using and developing F-Spot, and let's other users and developers do the same. Best Regards, Stephane -- Stephane Delcroix [EMAIL PROTECTED] _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
