Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGQtxvabhG0S=qJM+GnDtGUCRW08KYr4VZdif+juG-KiwnSL3Q@mail.gmail.com>
References: <20130514144130.GB24552@USLT-205755.sungardas.corp>
	<20130524162610.GY56667@USLT-205755.sungardas.corp>
	<079C1F44-C929-439E-8971-B815E7C01B2B@gmail.com>
	<CAPaJBx4fwarJZfzRuRz7_L8nOTGUUF_wO5qW-cv2Pb-r=ZV12w@mail.gmail.com>
	<9538CD10-F09F-48DC-AF0F-3E3956C67CC4@gmail.com>
	<CAGQtxvabhG0S=qJM+GnDtGUCRW08KYr4VZdif+juG-KiwnSL3Q@mail.gmail.com>
Date: Tue, 28 May 2013 22:43:46 +0100
Message-ID: 
 <CAPaJBx6D6-HoPg69ZZviROeHth1L1YwXsejq0gf656nCcMkU2g@mail.gmail.com>
Subject: Re: [DISCUSS] Should we be releasing -beta releases?
From: Noah Slater <nslater@apache.org>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=047d7b10d1dbeeb7ee04ddce28f8

--047d7b10d1dbeeb7ee04ddce28f8
Content-Type: text/plain; charset=ISO-8859-1

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.hoogland@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 <runseb@gmail.com
> >wrote:
>
> >
> > On May 28, 2013, at 2:36 PM, Noah Slater <nslater@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 <runseb@gmail.com> wrote:
> > >
> > >>
> > >> On May 24, 2013, at 12:26 PM, Chip Childers <
> chip.childers@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

--047d7b10d1dbeeb7ee04ddce28f8--