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

Re: Beta or RC by Wednesday evening

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 12 Mar 2008 13:49:15 -0400

Copy this from IRC and responding:

<kfogel_> glasser: I think Mark Phippard has a point. What are our
specific concerns about beta vs rc?

<glasser> do we actually have realistic experience using it ourselves
yet, before trying to sell the world on it? merge tracking
specifically. like, documentation, HOWTOs, etc

<glasser> if "we have merge tracking" is supposed to be the big
selling point of 1.5, then throwing out a tarball as "releasable"
without giving anyone any idea how to use the new features is kind of
poor

<glasser> (also, how's the issue tracker sweep, and the XFail sweep
going? sorry, I've been a little distracted by working on our own
install instead of upstream)

<kfogel_> glasser: so, I think the fact that we haven't checked over
the documentation (book, release notes, etc) is a good point.

<glasser> The fact that CHANGES is mostly done helps

<kfogel_> I'm working on release notes now, and I *really* want to
make sure we present merge tracking in a way that manages expectations
well. (I've called it "[foundational]" in the CHANGES file, for
example, but we'll need to get more specific than that.

<glasser> But yeah. I think "release candidate" means "people who
like living on the bleeding edge should seriously consider installing
this and getting real-world experience, as long as they understand the
risks involved". And it's not fair to make that request of our users
if we aren't ready to educate them as to what they can actually do

Now my response:

glasser seems to be raising 3 main issues to consider before RC:

1) Documentation of new features
2) Issue tracker sweep
3) XFail sweep

Documentation is always an issue, other than finishing the release
notes I do not see where we are lacking though. Especially if we are
comparing this to our previous releases. The book is in better shape
for 1.5 then it has been for any of the other post-1.0 releases. What
other documentation is needed and where do we put it? You have
singled out merge tracking, but what about other new features? I
guess we can always do better, but we need to hold up an RC for this?

Issue tracker sweep. Not sure if you have something specific in mind,
but it sure seems like we have paid more attention to the issue
tracker for this release than any other. What were you looking for us
to do? AFAIK, we have done everything that has been mentioned on this
list, but I could be overlooking some stuff.

XFail sweep. This certainly seems a legitimate point and I do not
know the answer. I hope the situation there is not too bad though as
it seems like we are awfully late in the release process for this not
to have been raised by someone (not pointing the finger at you or
anyone).

Anyway, I think those are all good points. I happen to think we are
doing pretty well in these areas (with possible exception of XFail).
Perhaps these can serve as a good discussion point about readiness.
If so, I would just reiterate that we ought to have a specific list of
things we need to do so that we at least know when we are done and
ready.

Finally, your first point was just about how we generally feel. All I
can say is that I do not see how we are ever going to feel better
other than proceeding towards release. If we just keep idling you are
not going to wake up one morning and just decide you feel like we are
ready. I do not think we would be running it for our own repository
if we did not feel comfortable that it represented an improvement over
1.4.6.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-12 18:49:37 CET

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.