Yep! Welcome!
On 28 May 2013 22:56, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > wow, > I obtained voting right by subscribing. Beats Verhoeven's view on the > matter, the starship troopers way ;) > > > On Tue, May 28, 2013 at 11:43 PM, Noah Slater <nsla...@apache.org> wrote: > > > Users are *by definition* people who do not vote. The minute a user votes > > they become a developer. ;) > > > > I agree with you that interaction with the user@ list should use > inclusive > > language, and should call for participation in the decision-making > process > > that happens on dev@. > > > > Daan, monitor this list for emails that start with [DISCUSS] and [VOTE]! > :) > > > > > > On 28 May 2013 22:37, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > > > > I am not a commiter and did not know there where things at all that I > > could > > > vote on. Nice to hear. What things? How to recognise them? > > > > > > regards, > > > Daan > > > > > > > > > On Tue, May 28, 2013 at 11:14 PM, Sebastien Goasguen <run...@gmail.com > > > >wrote: > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > -- > > NS > > > -- NS
