It's very encouraging to see lots of commits lately coming from a wide
range of people -- you can feel the Subversion hairball gathering mass
exponentially as it rolls down the slope. :-)
As the project gets bigger and more complex, we also need to be more
organized and coordinated about how we make progress. In a private
email recently, Greg Stein commented insightfully on some shortcomings
in the recent milestone 4 and 5 process. I'm sure many of you also
noticed that things were a bit chaotic toward the end there, as some
so-called M4 issues morphed silently into Alpha issues, and temporary
workarounds found their way into the code without clear explanations.
The problem here is not the presence of workarounds, nor the fact that
bugs sometimes turn out to be more complex than one originally
thought. These things are inevitable in any software project of
sufficient size.
The real problem was that the milestones were defined (completely my
fault, by the way) in an artificial, and therefore fragile, way: by
the specific issues to be resolved, rather than by user-visible
features. Had the milestones been defined in the latter more natural
and intuitive way, there would be a lot less chaos and slippery
compromise in meeting them, because any given prioritization decision
would be evaluated against a comprehensible goal.
Greg proposed instead to define milestones mainly in terms of a couple
of *big* features each -- these features would be what defines the
milestone.
Well, why don't I just let him say it, instead of trying to
summarize? Greg, hope it's okay that I quote this portion of your
mail:
> When we set out to define a milestone, the answer is to come up with a list
> of N items for that milestone, say where N is somewhere between 10 and 20
> items. Various bugs, minor features, and a few big things. That last bit is
> important: a *few* big things. Those two or three items define the
> milestone. The rest are "gimmees" or "low hanging fruit". If they make the
> milestone, then great. But we tell the other groups that M<whatever> will
> have <these> two or three items. Sure, other work will be included, but it
> will be at least those items. Then we lay out a *very* conservative timeline
> to reach those few items. If there is slack, then we get the gimmees. If
> there is no slack, then we just ship with the big items.
>
> And note: those items are real features that a biz person or a user or
> whomever can actually get a handle on and find *useful*. "passing the tests"
> is not something that they would care about or need. Heck, they're going to
> break several more times before we're done, so it isn't really something
> that is now behind us.
He went on to propose these:
M6 -- svn mv, svn cp, svn log
M7 -- tag, branch, merge (simple merge first, a-la CVS; iff time
permits, protect against repeated merges by using ancestry
sets, else put that off to post-1.0)
which IMHO are very sensible next steps.
The trick is, leave enough time for each so that you *know* you can
complete the milestone. Bug fixes happen along the way. It's not
that we don't continue to prioritize and work on bugs -- of course we
do -- but just that we define the milestone in terms of the features,
not the bugs. Alpha is feature-complete, and is the next milestone
after M7. The stretch from Alpha to Beta is when we *concentrate* on
bugs, instead of writing new features.
The wisdom of this course seems pretty self-evident, I hope y'all
agree :-). We don't need another chaotic scramble, we need to know
our goals and know when we've reached them.
In the next emails, I'll talk about technical details of the above
milestones, & will be posting them to the web site status page, etc.
Keep them patches coming,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:45 2006