[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Features, releases and team work

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-28 21:16:50 CEST

On 3/28/07, Karl Fogel <kfogel@red-bean.com> wrote:
> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
> > The lack of a driving goal with built in motivation has two end
> > results. First, you don't have the same core of developers doing the
> > work, because they're largely done with what they wanted to do.
> > Second, the ones you do have (both old and new) really are scratching
> > their own itches, which results in the kind of development you see
> > today, smaller features, less big-bang type releases that do
> > incredible new things, etc.
> Huh. Yet, I feel like there's if anything more development happening
> now, and that some of are biggest features are still in the pipeline
> (merge-tracking being the obvious example).

Yes, they are, but, as cmike explains it 'only 1 1/2 person are
working on them'. (And I agree with him.) To me that means we're
introducing a *lot* of code unknown to most of us. That's not only
slowing us down, or what you'd like to call it, but it's also a danger
to maintenance continuity.

> We seem to have a case of competing realities. *shrug* That's okay.
> As long as we continue to take over the world, I mean :-).

But it *is* at the hart of the matter: Justin doesn't want to be
committed to any other contributions than strictly his own, which is
fine, but, when we all do that, then why should I have to wait
releasing *my* pet peeve until Ben and Justin added theirs, possibly
blocking release for months? In other words, in this scenario we
release regularly with what we have, because nobody's pet peeve is a
general agreed upon feature which needs to get to market.

But on the other hand, when we get commitment on a given roadmap,
having people work on their pet peeve is fine as long as it doesn't
hold back the generally agreed upon feature too much. In this scenario
we don't release regularly, but only when the given feature has been
satisfactorily implemented (which may be months later).

I see a big difference in philosophy here and I do think it's not
something to shrug about really, because as long as we don't actually
choose for one or the other, I'm feeling we're going to have last
weeks discussion on every release.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 28 21:17:08 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.