On 3/28/07, Karl Fogel <kfogel@red-bean.com> wrote:
>
> "Mark Phippard" <markphip@gmail.com> writes:
> > No one has replied to my suggestion, and I think it strikes a
> > compromise. We still have a roadmap, we try to stick to the roadmap,
> > but we take timeline into consideration when planning the roadmap.
> > Whether that is one release every 6-8 months or 10-12 months is just a
> > detail. I think that an approach like this can satisfy both camps and
> > also lead to less conflict. If there is no basic roadmap then it
> > seems inevitable that there are going to be disagreements about
> > whether we have enough to do a release. If we have a roadmap that
> > defines the goals for the release, then we can always say, feature X
> > is taking longer than we thought, lets push that to the next release
> > and do a release now.
>
> Okay, so in this plan it would be okay to sometimes release without a
> major, release-defining feature? (I've no problem with that, I just
> want to make sure I understand correctly.)
>
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Thu Mar 29 01:52:34 2007