On May 24, 2013, at 12:26 PM, Chip Childers <chip.child...@sungard.com> wrote:
> On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote: >> As a way to get more user feedback on our major feature releases, what >> does everyone think about releasing one or two -beta releases for each >> major feature release? >> >> This might fall in line with some of the stated concerns about our >> release schedule (see [1]). I've stated a desire to be quicker about >> our releases (my vote was 4 months). I've also been saying quite >> publicly that we should never release if we know about upgrade issues >> (that's the cost of having actual users of our project, which I'm more >> than willing for us to pay). >> >> Perhaps -betaX releases would be helpful to get attention from the users >> to test the release (including upgrade paths). The stated assumption >> could be: -beta releases are not releases that can be upgraded *from*, >> but are intended to help support testing by end users that want to check >> the upcoming release against their expected feature set and upgrade >> path. >> >> I would see the first -beta-1 being released about 1 month after feature >> freeze. For example, for 4.2.0, it would be on 2013-06-30. I would >> only do a -beta-2 (or later) beta release if required due to testing >> results. I would also suggest that the -beta-* releases would *not* >> have any particular quality criteria (well... perhaps minimal, like >> blocking on issues that fundamentally make the software unstable). >> >> I'm not sure about my own proposal here, but I wanted to throw it out >> and see if any of you have feedback / thoughts. >> >> -chip >> >> [1] http://markmail.org/message/3ctdwor5hfbpa3vx > > To summarize the discussions of this thread: > > 1) The idea of ensuring that we get user testing of release candidates > is one that most agree with. > > 2) Concerns were raised about the overhead of "officially" releasing > beta releases, especially if there is any expectation that there would > be an upgrade path from a -beta to an official release. > > I'd like to simplify this by saying that we should actually plan on > announcing the start of each round of voting on RC's to the users@ list. > We can get feedback from them on each round. Why don't we include users@ in the voting thread in the first place ? The entire community can vote, correct ? committers and non-committers. Asking @users for feedback make it sound a little bit like feedback is welcome but not voting. > And while I don't really > love having a bunch of rounds of voting, 4.1.0 has basically proven that > user engagement testing the RC's is critical. I think that we might > also consider (at a release manager's discretion) periodically > announcing a request for testing of the feature branch's code during the > QA part of our release cycles. +1 > > Shout if you disagree.
