[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-03-28 18:52:09 CEST

On 3/28/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> On 3/28/07, Mark Phippard <markphip@gmail.com> wrote:
> > organizations for moving to Subversion in the first place. How do we
> engage
> > the entire community to focus on the goal of delivering a feature like
> that?
> > If we just keep doing quick releases, I do not think you are going to
> get
> > developers to tackle these big issues.
> I'm gonna sound like a broken record here, but...
> Roadmaps are going to mean little without committed developer
> resources. IMO, the way you get developers to tackle these big issues
> is to find someone who really wants this feature and get them to code
> it themselves or pay someone directly to work on it.
> Altruism will get you a little productivity bump - but for me,
> Subversion does most of the things that I care about. Compare that to
> where SVN was when I first contributed in late 2001 - there was lots
> of stuff that didn't work - but I've been around long enough now that
> most of what I want is there. So, I'm quite happy with our forward
> progress. *shrug* -- justin

I agree with this somewhat, but let me try to explain the ways I disagree
and why I do not think it is "altruism".

First, before something can get put on the Roadmap there needs to be some
degree of developer commitment. One or more developers should be prepared
to say that they can provide their best efforts towards getting feature X
done for timeline Y. Maybe that includes someone like you saying, "I am
not real interested in that feature, but I am willing to help out with the
parts that involve ra_serf".

Obviously these things are not carved in stone. As an example, there was
obviously a time when Garrey was working for CollabNet that he was
"assigned" to work on true renames. When he left CollabNet I see nothing
wrong with him telling the community that he can no longer work on that
feature, and if no one else steps up to take his place we withdraw the item
from the roadmap and toss it back in the list.

Finally, the community needs to stand behind its roadmap as long as there is
not some reason like the one above to make a change. This is hopefully
where we can engage the developers. If you really want to see a release get
put out, but some feature we slotted for the roadmap is holding it up, then
maybe that is the itch you need to contribute to that feature and help see
it to completion. I think the current situation with 1.5 and merge tracking
is a good example of this, with one really big exception and that is that we
never formally agreed as a community that this is our roadmap and that
1.5included the merge tracking feature. So I think it is not
unreasonable for
some people to say that they never agreed 1.5 should have been defined that
way. But otherwise, clearly the developer effort has been made to deliver
the feature and if we want it sooner. maybe we just need more people to
pitch in and help deliver it.

Like it or not, Subversion is a big time tool now. There are a lot of
people downstream from us that depend on us to provide a clear roadmap and
then deliver it so that they can build their schedules and expectations
around it. This includes the large hosting services, related tools like
TortoiseSVN and Subclipse, distributions and packagers, users, and yes
corporations. I do not see any reason we cannot come together to produce a
roadmap and then do our best to stick to it when at all possible and
communicate it when we cannot.

Mark Phippard
Received on Wed Mar 28 18:52:37 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.