On 3/28/07, Erik Huelsmann <ehuels@gmail.com> wrote:
>
> > 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.
> >
> > Honestly, I'm not sure there's a good way to "fix" this, and I'm not
> > sure it really needs to be fixed anyway. In many ways it just is what
> > it is.
>
> But, if that's what it is, can we agree on that and not make a big
> deal out of releases and just release every 6 months what we *do*
> have?
>
> I'm torn between your position and the 'ok lets do this big feature,
> but do it all together'.
I have no problem in general with doing more focused releases on a shorter
schedule, but I think the problem we have to solve is how do we do that and
still get "big-feature" work done? For example, support for true renames is
hugely important (IMO) and a large amount of work. I am surprised more
users are not killing us over this feature. The people that run into it are
truly burned by it and often wind up losing support within their
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 think the answer is that you plan a roadmap. If we want 6 month timelines
to drive the roadmap, that is fine. Let's define what we can do in each 6
month cycle. Where I think we might differ in opinion is that I would say
you do not do the release until you have met the goals for that iteration.
We do not release because the 6 month clock has completed, we release
because the features are done. We would then just have to be realistic
about what we schedule in that 6 month cycle so that we can get it all done
on time.
I think to get started, we should try to create some kind of whiteboard page
where people can list the enhancements they would like to see made to
Subversion. We can then start to use that list to sketch out a roadmap of
releases. Getting back to my example of true renames, maybe we decide that
the first 6 month cycle will include the repository and working-copy level
changes to capture a rename event, and the next 6-month cycle will involve
leveraging that information in commands like update and merge.
It probably could not hurt to create a little bit of process around the
whiteboarding of ideas either. For example, maybe there is some general
list of ideas, but to get that idea to a place where will consider including
it in a release roadmap someone has to take the idea a little further and
flesh it out with a spec that is agreed upon and which we can then have an
idea for time involved.
I do not want to take away the ability of an individual developer to scratch
an itch and submit a great new feature to the project. I also do not want
to hold a bunch of nice enhancements in trunk forever while big features are
being developed. That being said, I think the merge tracking feature could
already be done if it has received more attention from the community as a
whole. Going forward, we need to figure out how some of the rest of the
similar big features are going to get done and receive the attention and
priority they deserve from the community as a whole.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Wed Mar 28 16:34:03 2007