On Thu, May 5, 2011 at 6:07 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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 wouldn't plan on holding the release pending feedback. We can
invite people to provide it, but should they choose not to, we move
ahead.
One of the reasons I want to do alphas and/or betas is to test the
actual artifact creation and distribution. A lot has changed in the
tarball rolling process since 1.6.x (we don't create deps, various
swig building changes), and we've not released on apache
infrastructure before. I'd like to iron out any kinks in the rolling
process before I create a borked rc1 (or rc2, ad nauseum).
>> 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.
Historical reasons, mainly. If folks are comfortable cutting an alpha
release from trunk, I'm fine too. It may require a slight
modification of our dist scripts, though.
>> 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.
I like this plan, and don't mind proposing something similar in a
separate thread (wherein people can debate the branch date, etc.)
>> 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.
I agree with using the 1.7.0 milestone as that for blocking problems.
I currently see only 10 issues marked as such, an improvement over the
past couple of weeks.
-Hyrum
Received on 2011-05-09 21:42:04 CEST