"Mark Phippard" <markphip@gmail.com> writes:
> Short answer ... absolutely.
>
> Longer answer, and I tried to say this in the original reply, was that
> we could decide we were going to define roadmap releases based on time
> frame, as opposed to features, and we would then have to define what
> would go in each release based on the timeframe. So maybe it would be
> smaller features like SASL support, WC improvements, maybe it would be
> part of a larger feature such as the repository backend support for
> true renames.
>
> The second part of this answer, is that I think we always have the
> option as a community to change our mind. Suppose we had agreed merge
> tracking was one of the defining features for 1.5 on this hypothetical
> roadmap, and we had slated that release for 1Q 2007. As we got closer
> to the release time Daniel could have said "sorry guys, but I do not
> think this can be ready until late 2Q." We could then decide to push
> merge tracking to the next release, or try to provide more effort so
> that it was ready for early 2Q. Having agreed to our goals ahead of
> time, the conversation that needs to happen would just be easier to
> have because we could eliminate the discussion of whether we agreed to
> this in the first place.
>
> I do have some concerns about basing the roadmap on timeframes. I
> think that sort of concept only works well if the timeframes are short
> (6 months max). The problem we might have with that approach is
> having too many releases. Do our downstream users want them that
> frequently? I think the client tools and packagers might have the
> toughest time with this, although I am sure both would benefit from
> the predictability. I think with a "major" release every 6 months,
> and then assuming there are also fix releases happening in between,
> that is a lot of releases to be producing and a lot of work related to
> that. I am not against doing it this way, I just think if we are
> going to make time the main factor, then the time ought to be
> relatively short. It would really suck if a major feature like true
> renames missed a release by a month and then had to be held for
> another 8 months before we do another release.
>
> I actually think the first thing we should do is start compiling the
> roadmap wishlist of what features we want to provide. That might help
> us decide what we actually want to do in terms of scheduling. I have
> to say that this has felt like "rename" week for me. I have seen the
> issue come up several times on the lists as well as internally from
> CollabNet customers. I have always thought this was a major hole in
> the product because the only workaround that works is to not do
> renames. I'd like to see that developers are interested in making
> this a priority item on the post 1.5 roadmap. I know it is a big
> task.
I guess I can see people rallying around a particular feature, but not
around a roadmap. (Or, they might rally around the roadmap, but that
won't have much effect in the long run.)
When I said I could see myself reorganizing my personal priorities to
be in line with a team effort, I meant more around a particular
release or feature. I'm not sure a roadmap would make things better
faster; there are advantages to the controlled chaos we've got going
on here, after all.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 29 02:51:06 2007