On Thu, May 5, 2011 at 6:02 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> We've still got bugs (we'll always have bugs), but I think getting
> more testing via the pre-releases is important at this stage, and I
> see branching as a step toward cutting pre-releases.
I am not a huge fan of alpha/beta releases. I just do not think they
provide a lot of value as you rarely get back any feedback. We did
this with 1.5 and even put a fair amount of effort into publicizing it
and providing binaries etc. Yet I recall we did not start getting any
real feedback and evidence that people were looking at the releases
until we got to the final release candidates and it was getting
obvious we were about to release.
I realize there are some projects that have had success with this sort
of thing, I just do not think we are one of them. My main concern is
that it would actually slow down the release process as we get to a
point where we are somewhat waiting for feedback that never arrives.
> I do not think we need to have trunk in a releasable state before
> branching, but I would like to find a way to start doing pre-releases
> relatively soon-ish. I suppose we could cut alpha releases directly
> from trunk, but that would be a break with precedent, and doesn't
> really feel good.
What is your concern with this? I do not see why it would be a
problem. I am not sure what your definition of "releaseable state"
is, especially in regards to an alpha/beta release, but I think trunk
is in this state. I have been publishing Windows binaries of trunk
builds and I believe that TortoiseSVN does as well.
> If the branch is not in a releasable state, I'd propose we cut alpha
> or beta releases, and release them along with a list of known issues,
> similar to what we did for 1.5. This would allow more testing.
> Voting rules on the branch could be relaxed up until the first release
> candidate, also similar to 1.5, in an effort to get changes on to the
> release branch with as little friction as possible.
If we really wanted to do something, I would suggest something like this.
1) Define a reasonable target date when we think we are going to
branch and be ready for RC1. Let me just make up a date and say June
8th,
2) Issue a beta1, beta2, beta3 like clockwork every week leading up to
the date. These would just be cut from trunk and go through no or
minimal voting. I would probably just be sure to use a revision where
buildbot is green.
3) Publicize these plans and the betas leading up to it. Each beta
should list the known issues that are currently blocking the release.
Encourage users to report issues they see as release blockers.
4) We should obviously try to meet the date we set for ourselves as
other open-source projects do, but obviously the software has to be
ready to actually get to that final branch/rc1 state. All known
release blockers must be closed and the release would go through
normal release process.
> This feels like something that could happen before the end of the
> month, but I'm sure others have insight into what is blocking the
> branch, so please speak up.
I have been encouraging people to use the 1.7.0 milestone for anything
that is a blocker. Paul added issues for every XFail and annotated
the tests. Other things that normally slow us down like release notes
and CHANGES seem good. I think we should rely on the issue tracker to
enumerate the blockers. If people cannot be bothered to create an
issue for something than it is not a blocker.
BTW, I agree things are looking good.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-05-06 01:08:04 CEST