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

Re: Ready for RC1

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Thu, 06 Mar 2008 21:38:14 -0600

Mark Phippard wrote:
> I'd like to begin the discussion on when we will be ready for RC1. I
> think we should do it soon. There are no specific fixes/features that
> anyone is working for in 1.5, we are basically just waiting for users
> to find and report bugs. If we release an RC1 we will get more users
> using it and we can get more feedback which gets us to GA. This
> alpha/beta process would be fine if we knew we had specific work left
> to do, but I do not see where that is the case.

I want to be sure we feel comfortable releasing something as 1.5.0
before we start calling it a release candidate. That should be the
litmus test. If the code currently in 1.5.x troubles people, we should
call it a beta.

The other consideration is that once we go to RC, we've agreed that the
full stabilization voting rules go into effect. That shouldn't be a
problem, but if we think there will still be a fair amount of
backporting, we may want to hold off on an RC just yet. (Then again, if
we think there may be a fair amount of backporting, perhaps we shouldn't
be releasing it as an RC....)

> I am not proposing we roll a tarball this weekend. Just that we come
> up with the end plan to get there.

I'm fine with not rolling an alpha this weekend, and waiting until
STATUS shrinks a bit before rolling a beta or rc.

[On a philosophical note, I don't see myself as the guy who dictates
/when/ we release, so much as the guy who pushes the button to get the
release process rolling when we do decide to do a release (alpha, beta,
rc, whatever). I prefer the "when" question be answered by the
community. I try not to appear too dictatorial in declaring goals for
rolling releases; I'm just helping give people a target to shoot toward
for backports.]

> These are the things I think need to be done to get to RC1. All could
> be done relatively quickly.
>
> 1) Propose any remaining items for backport. I went through all the
> un-proposed changes in trunk (merge tracking makes this easy) and
> picked out the ones that MAYBE we want to propose.
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=135809
>
> The original author should probably make the proposal. That would be
> (cmpilato, glasser, joe orton, kfogel).
>
> 2) Vote on these items (and existing proposals) and get them merged to
> the branch.
>
> 3) Finish the work on the CHANGES file. Karl has taken this on and
> seems to be making progress.
>
> 4) Finish the work on the release notes. I know that Hyrum started
> this. I am sure there is more to do.

I'm not trying to put words in his mouth, but according to
http://svn.haxx.se/dev/archive-2008-03/0131.shtml Karl also plans on
finishing up the Release Notes.

> I think we should do these items and move on to the RC1 process. If
> you disagree with this, then just please explain why, and even better
> please list the things that you think need to happen to get us to RC1.
> Please be as specific as possible. I will do whatever I can to drum
> up the resources necessary to make these things happen (assuming there
> is consensus they need to be done).
>
> We have made great progress towards the release and I just want to
> keep things moving. If there are still some things that have to be
> done, I would like to see them identified so that I have a chance to
> help knock them off the list and get this release finalized. I am not
> proposing we go GA before this is ready or that we sidestep any of our
> procedures. I just want to help get us to the finish line as fast as
> possible so we can get on with our plans for the future. I also
> happen to think the current software is looking really good.

So do I. :)

-Hyrum

Received on 2008-03-07 04:38:30 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.