cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Should we be releasing -beta releases?
Date Tue, 28 May 2013 21:43:46 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message