On May 28, 2013, at 2:36 PM, Noah Slater <nsla...@apache.org> wrote:
> Sebastien, > > Nope, we don't do votes on the users@ list. That list is just for user > support. > > Decision making happens on dev@*, and if users want to take part in that, > they can subscribe. This needs to be made clearer then, otherwise it seems that users are really second class citizens and that they are not allowed to vote. Chip's email to users@ says something like "we welcome your feedback", which is different than "if you want to vote, you can by registering to the dev list and casting your vote there" > > * Or marketing@, private@, and security@ > > > On 27 May 2013 08:53, Sebastien Goasguen <run...@gmail.com> wrote: > >> >> 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. >> >> > > > -- > NS
