Fwd: F-Spot: goals and milestones

["Ben Monnahan" <monnahan gmail com>]

This was meant for the list...

---------- Forwarded message ----------
From: Ben Monnahan <monnahan gmail com>
Date: 23-jul-2006 10:45
Subject: Re: F-Spot: goals and milestones
To: Stephane Delcroix <stephane delcroix org>

In general I agree with pretty much everthying in this email, but I'll respond to some specific points below.

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.

I'm a little unclear on what you mean by CoreDevelopers.  Do you mean those who have submitted a number of nontrivial patches? Those with commit access?  It seems to me that Larry is the only one who has the overall vision of what F-Spot is going to be, or at least for now, commits are limited to him. (He has shown interest in changing that but as of now no one has stepped up)  Its a good idea, but since he is the limiting factor for other more important steps, I'm not sure how feasable it is.  I for one would not feel comfortable rejecting most of the enhancements/bugs but maybe others do feel differently.
 

- Some enhancement requests are pretty cool. Fix this as a GOAL to
achieve. Even if there's no patch to fulfill the request.

This is a good idea, to help the important ones filter to the top.
 

- 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.

These seem unrelated to me, maybe I'm not understanding it correctly.  1) would be nice to have short-term/long-term plans to help direct the effort, but for now there seems to be plenty of interest making a variety of improvements so I'm not overly concerned.  2) Reviewing is good, but CVS isn't a release either, so some sort of balance.  Pushing code to CVS gets a much wider variety of testers.  Having at least one review per non-trivial patch would be comforting.
 

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).

This is a big one.  Its not a fun as writing your own patch, but it takes a lot of work off Larry's shoulders and hopefully improves the quality of code committed to CVS.  Big patches should be avoided when possible (I'm saying as much to myself as others, if not more) because it makes the review process much more difficult.
 

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, ...)

Meetings/Milestones sound like a great idea.  I know Larry showed interest in extending CVS write access to others, but that is much more dependent on us (non-committers) to step up and earn it.
 

* 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!

It would be great to get the trivial patches in. 

 

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.

One of the successes happening in Ubuntu, is they have non-developers starting to help with bug triage.  It's a great way to get involved if you don't have interest in coding.
 

And what about fixing a meta-goal ? like reducing the bug count to less
than 200 for the end of the year (or quicker) ???

That sounds committal.  :)

 

* 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, ...)

I think this will come as a side effect of getting the patches into CVS, it will be evident that releases need to be made.

Best Regards,

Stephane
--
Stephane Delcroix
stephane delcroix org

Great email Stephane!

Ben