You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2013/05/14 16:41:30 UTC
[DISCUSS] Should we be releasing -beta releases?
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
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nux! <nu...@li.nux.ro>.
On 14.05.2013 15:41, 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?
Good idea! It would be great to get a feel of how things will look and
work ahead of release! This could also allow people who want to do
production deployments match their efforts with your development cycle
(if said betas will be upgradable to release).
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
+1
We could do an RC type thing. I wouldn't feel bad if we ship every release we vote for as a RC release. The last RC release that wins the vote will turn into the regular release.
Cheers,
Hugo
> -----Original Message-----
> From: Joe Brockmeier [mailto:jzb@zonker.net]
> Sent: Tuesday, May 14, 2013 4:49 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>
> On Tue, May 14, 2013, at 09:41 AM, 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?
>
> Yes to beta releases. I know that users could test at any time, but we need
> explicit targets for users that say "now is a good time to test this and give
> feedback."
>
> +1
>
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
upgrades are a valid point. No one tests those as a user does.
On Tue, May 14, 2013 at 4:03 PM, Chip Childers <ch...@sungard.com>wrote:
> On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> > As a relative outsider;
> >
> > any branch that is not released yet is a beta release. Why make it more
> > explicit. Wouldn't this add support burdon? Make a branch 'in beta' and
> > appoint a guard to make sure no new feartures but only fixes go in (kind
> of
> > how you are working right now)
>
> So we do that today. However, a "release" as a -beta will get more user
> attention eariler in our release cycle (at least that's my theory). We
> need that user attention to help us ensure that upgrades work.
>
> >
> > Daan
> >
> >
> > On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net> wrote:
> >
> > > On Tue, May 14, 2013, at 09:41 AM, 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?
> > >
> > > Yes to beta releases. I know that users could test at any time, but we
> > > need explicit targets for users that say "now is a good time to test
> > > this and give feedback."
> > >
> > > +1
> > >
> > >
> > > Best,
> > >
> > > jzb
> > > --
> > > Joe Brockmeier
> > > jzb@zonker.net
> > > Twitter: @jzb
> > > http://www.dissociatedpress.net/
> > >
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Prasanna Santhanam <ts...@apache.org>.
On Sat, May 18, 2013 at 06:51:30PM -0700, Ahmad Emneina wrote:
> I agree, there need's to be a caveat the nightly builds are convenience
> builds, that shouldnt be used for any type of production environment. Only
> for testing.
>
>
> On Sat, May 18, 2013 at 4:43 PM, Marcus Sorensen <sh...@gmail.com>wrote:
>
> > I like this idea, as long as it is approached carefully. I would prefer
> > that the beta releases be of failed RC quality than pre-RC phase. I know
> > these should be at their own risk, take backups, etc, but upgrades are
> > notorious for schema upgrade failures. Also, helping people update from
> > beta 1 to RC2 and all of the possible permutations seems like a nightmare
> > if the database schema/ updates aren't rock solid before the first beta is
> > cut.
> > On May 18, 2013 4:56 PM, "Ahmad Emneina" <ae...@gmail.com> wrote:
> >
Until a while ago (and purely because we ran out of space on Jenkins
master) we hosted artifacts of the nightly packages for those who'd be
interested in test driving the new features. That can be enabled back
if required during the VOTING phase of a release.
But I'm getting slightly confused by the +1s in this discussion:
1. For nightly build/bleeding edge/no-upgrade-support packages - +1
(If someone has a public s3 repo, I can turn it into a yum/apt repo
for these)
2. For supporatable betas that can be upgraded to RC/GA quality - -1
I don't think our upgrades, release cadence discpilines are there yet
for that. This could be useful in the future though.
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Ahmad Emneina <ae...@gmail.com>.
I agree, there need's to be a caveat the nightly builds are convenience
builds, that shouldnt be used for any type of production environment. Only
for testing.
On Sat, May 18, 2013 at 4:43 PM, Marcus Sorensen <sh...@gmail.com>wrote:
> I like this idea, as long as it is approached carefully. I would prefer
> that the beta releases be of failed RC quality than pre-RC phase. I know
> these should be at their own risk, take backups, etc, but upgrades are
> notorious for schema upgrade failures. Also, helping people update from
> beta 1 to RC2 and all of the possible permutations seems like a nightmare
> if the database schema/ updates aren't rock solid before the first beta is
> cut.
> On May 18, 2013 4:56 PM, "Ahmad Emneina" <ae...@gmail.com> wrote:
>
> > I like the idea of nightly builds. Hopefully it could be tied into
> Jenkins
> > and have passed some sort of quality check. That way only known 'good'
> > builds are exposed.
> >
> > Ahmad
> >
> > On May 17, 2013, at 5:32 AM, Noah Slater <ns...@apache.org> wrote:
> >
> > > We need to be careful about how we approach this. A "release" is
> > something that is voted on. A "release candidate" is something that is
> > about to be voted on. If you you don't vote on something, it's not a
> > release. And if you've voted on something, it's no longer a candidate. :)
> > >
> > > Two things we could do:
> > >
> > > * Vote on, and officially release, beta/alpha versions. (This comes
> > with the overhead of the release procedure, and community fatigue of the
> > voting/testing cycle.)
> > >
> > > * Set up easy-to-access nightlies. Link to them from a place on the
> dev
> > section of the site, and make sure that people who we send there release
> > that these are _not_ releases.
> > >
> > >
> > > On 17 May 2013 07:56, Nitin Mehta <Ni...@citrix.com> wrote:
> > >> +1.
> > >> Need the beta especially because folks would want to test early and
> > >> crossing the last mile can take a bit of time.
> > >> But hopefully its not too much of an overhead.
> > >>
> > >> Thanks,
> > >> -Nitin
> > >>
> > >> On 16/05/13 7:27 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
> > >>
> > >> >+1, perhaps I'm late to this thread, but this makes lot of sense.
> > >> >
> > >> >
> > >> >-------- Original message --------
> > >> >From: Pranav Saxena <pr...@citrix.com>
> > >> >Date:
> > >> >To: dev@cloudstack.apache.org,aemneina@gmail.com
> > >> >Subject: RE: [DISCUSS] Should we be releasing -beta releases?
> > >> >
> > >> >
> > >> >+1 to what Ahmad says here . Perfect reasoning .
> > >> >
> > >> >There have been many users on the list asking for some capability
> > >> >/feature present in CloudStack when it's actually under development
> in
> > >> >the current release. Beta release would allow them to get a feel of
> it
> > .
> > >> >Definitely , it would help to further refine any new feature further
> > when
> > >> >actually tested in a production environment .
> > >> >
> > >> >-----Original Message-----
> > >> >From: Ahmad Emneina [mailto:aemneina@gmail.com]
> > >> >Sent: Wednesday, May 15, 2013 12:07 AM
> > >> >To: dev@cloudstack.apache.org
> > >> >Subject: Re: [DISCUSS] Should we be releasing -beta releases?
> > >> >
> > >> >+1
> > >> >I feel this allows for users who are chomping at the bit to get a
> hold
> > of
> > >> >feature X. Tinker with feature X, expose bugs or use case issues well
> > >> >before an official release. Saves on the disappointment as well. ;)
> > >> >
> > >> >
> > >> >On Tue, May 14, 2013 at 9:34 AM, Chip Childers
> > >> ><ch...@sungard.com>wrote:
> > >> >
> > >> >> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> > >> >> > Are you going to support upgrades from your Betas to release (and
> > >> >> > betaN to betaN+1)?
> > >> >> > If the answer is no, then there is no interest on my part. It's
> not
> > >> >> > better than us producing nightly builds, or highlighting jenkins
> > >> >> > builds.
> > >> >>
> > >> >> Perhaps doing a better job of highlighting nightly builds at key
> > >> >> moments is the right answer to the problem I was trying to solve
> > (more
> > >> >> user testing of upgrades)?
> > >> >>
> > >> >> The beta idea comes with some overhead, and perhaps that overhead
> > >> >> isn't worth the benefit (if there are other ways to achieve that
> > >> >> goal). And that's why I floated the idea... to get reactions.
> > >> >>
> > >> >> >
> > >> >> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> > >> >> > <ch...@sungard.com> wrote:
> > >> >> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> > >> >> > >> As a relative outsider;
> > >> >> > >>
> > >> >> > >> any branch that is not released yet is a beta release. Why
> make
> > >> >> > >> it
> > >> >> more
> > >> >> > >> explicit. Wouldn't this add support burdon? Make a branch 'in
> > beta'
> > >> >> and
> > >> >> > >> appoint a guard to make sure no new feartures but only fixes
> go
> > >> >> > >> in
> > >> >> (kind of
> > >> >> > >> how you are working right now)
> > >> >> > >
> > >> >> > > So we do that today. However, a "release" as a -beta will get
> > >> >> > > more
> > >> >> user
> > >> >> > > attention eariler in our release cycle (at least that's my
> > >> >> > > theory). We need that user attention to help us ensure that
> > >> >>upgrades work.
> > >> >> > >
> > >> >> > >>
> > >> >> > >> Daan
> > >> >> > >>
> > >> >> > >>
> > >> >> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <
> jzb@zonker.net
> > >
> > >> >> wrote:
> > >> >> > >>
> > >> >> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> > >> >> > >> >
> > >> >> > >> > Yes to beta releases. I know that users could test at any
> > time,
> > >> >> > >> > but
> > >> >> we
> > >> >> > >> > need explicit targets for users that say "now is a good time
> > to
> > >> >> > >> > test this and give feedback."
> > >> >> > >> >
> > >> >> > >> > +1
> > >> >> > >> >
> > >> >> > >> >
> > >> >> > >> > Best,
> > >> >> > >> >
> > >> >> > >> > jzb
> > >> >> > >> > --
> > >> >> > >> > Joe Brockmeier
> > >> >> > >> > jzb@zonker.net
> > >> >> > >> > Twitter: @jzb
> > >> >> > >> > http://www.dissociatedpress.net/
> > >> >> > >> >
> > >> >> >
> > >> >>
> > >
> > >
> > >
> > > --
> > > NS
> >
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Marcus Sorensen <sh...@gmail.com>.
I like this idea, as long as it is approached carefully. I would prefer
that the beta releases be of failed RC quality than pre-RC phase. I know
these should be at their own risk, take backups, etc, but upgrades are
notorious for schema upgrade failures. Also, helping people update from
beta 1 to RC2 and all of the possible permutations seems like a nightmare
if the database schema/ updates aren't rock solid before the first beta is
cut.
On May 18, 2013 4:56 PM, "Ahmad Emneina" <ae...@gmail.com> wrote:
> I like the idea of nightly builds. Hopefully it could be tied into Jenkins
> and have passed some sort of quality check. That way only known 'good'
> builds are exposed.
>
> Ahmad
>
> On May 17, 2013, at 5:32 AM, Noah Slater <ns...@apache.org> wrote:
>
> > We need to be careful about how we approach this. A "release" is
> something that is voted on. A "release candidate" is something that is
> about to be voted on. If you you don't vote on something, it's not a
> release. And if you've voted on something, it's no longer a candidate. :)
> >
> > Two things we could do:
> >
> > * Vote on, and officially release, beta/alpha versions. (This comes
> with the overhead of the release procedure, and community fatigue of the
> voting/testing cycle.)
> >
> > * Set up easy-to-access nightlies. Link to them from a place on the dev
> section of the site, and make sure that people who we send there release
> that these are _not_ releases.
> >
> >
> > On 17 May 2013 07:56, Nitin Mehta <Ni...@citrix.com> wrote:
> >> +1.
> >> Need the beta especially because folks would want to test early and
> >> crossing the last mile can take a bit of time.
> >> But hopefully its not too much of an overhead.
> >>
> >> Thanks,
> >> -Nitin
> >>
> >> On 16/05/13 7:27 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
> >>
> >> >+1, perhaps I'm late to this thread, but this makes lot of sense.
> >> >
> >> >
> >> >-------- Original message --------
> >> >From: Pranav Saxena <pr...@citrix.com>
> >> >Date:
> >> >To: dev@cloudstack.apache.org,aemneina@gmail.com
> >> >Subject: RE: [DISCUSS] Should we be releasing -beta releases?
> >> >
> >> >
> >> >+1 to what Ahmad says here . Perfect reasoning .
> >> >
> >> >There have been many users on the list asking for some capability
> >> >/feature present in CloudStack when it's actually under development in
> >> >the current release. Beta release would allow them to get a feel of it
> .
> >> >Definitely , it would help to further refine any new feature further
> when
> >> >actually tested in a production environment .
> >> >
> >> >-----Original Message-----
> >> >From: Ahmad Emneina [mailto:aemneina@gmail.com]
> >> >Sent: Wednesday, May 15, 2013 12:07 AM
> >> >To: dev@cloudstack.apache.org
> >> >Subject: Re: [DISCUSS] Should we be releasing -beta releases?
> >> >
> >> >+1
> >> >I feel this allows for users who are chomping at the bit to get a hold
> of
> >> >feature X. Tinker with feature X, expose bugs or use case issues well
> >> >before an official release. Saves on the disappointment as well. ;)
> >> >
> >> >
> >> >On Tue, May 14, 2013 at 9:34 AM, Chip Childers
> >> ><ch...@sungard.com>wrote:
> >> >
> >> >> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> >> >> > Are you going to support upgrades from your Betas to release (and
> >> >> > betaN to betaN+1)?
> >> >> > If the answer is no, then there is no interest on my part. It's not
> >> >> > better than us producing nightly builds, or highlighting jenkins
> >> >> > builds.
> >> >>
> >> >> Perhaps doing a better job of highlighting nightly builds at key
> >> >> moments is the right answer to the problem I was trying to solve
> (more
> >> >> user testing of upgrades)?
> >> >>
> >> >> The beta idea comes with some overhead, and perhaps that overhead
> >> >> isn't worth the benefit (if there are other ways to achieve that
> >> >> goal). And that's why I floated the idea... to get reactions.
> >> >>
> >> >> >
> >> >> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> >> >> > <ch...@sungard.com> wrote:
> >> >> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> >> >> > >> As a relative outsider;
> >> >> > >>
> >> >> > >> any branch that is not released yet is a beta release. Why make
> >> >> > >> it
> >> >> more
> >> >> > >> explicit. Wouldn't this add support burdon? Make a branch 'in
> beta'
> >> >> and
> >> >> > >> appoint a guard to make sure no new feartures but only fixes go
> >> >> > >> in
> >> >> (kind of
> >> >> > >> how you are working right now)
> >> >> > >
> >> >> > > So we do that today. However, a "release" as a -beta will get
> >> >> > > more
> >> >> user
> >> >> > > attention eariler in our release cycle (at least that's my
> >> >> > > theory). We need that user attention to help us ensure that
> >> >>upgrades work.
> >> >> > >
> >> >> > >>
> >> >> > >> Daan
> >> >> > >>
> >> >> > >>
> >> >> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jzb@zonker.net
> >
> >> >> wrote:
> >> >> > >>
> >> >> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> >> >> > >> >
> >> >> > >> > Yes to beta releases. I know that users could test at any
> time,
> >> >> > >> > but
> >> >> we
> >> >> > >> > need explicit targets for users that say "now is a good time
> to
> >> >> > >> > test this and give feedback."
> >> >> > >> >
> >> >> > >> > +1
> >> >> > >> >
> >> >> > >> >
> >> >> > >> > Best,
> >> >> > >> >
> >> >> > >> > jzb
> >> >> > >> > --
> >> >> > >> > Joe Brockmeier
> >> >> > >> > jzb@zonker.net
> >> >> > >> > Twitter: @jzb
> >> >> > >> > http://www.dissociatedpress.net/
> >> >> > >> >
> >> >> >
> >> >>
> >
> >
> >
> > --
> > NS
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Ahmad Emneina <ae...@gmail.com>.
I like the idea of nightly builds. Hopefully it could be tied into Jenkins and have passed some sort of quality check. That way only known 'good' builds are exposed.
Ahmad
On May 17, 2013, at 5:32 AM, Noah Slater <ns...@apache.org> wrote:
> We need to be careful about how we approach this. A "release" is something that is voted on. A "release candidate" is something that is about to be voted on. If you you don't vote on something, it's not a release. And if you've voted on something, it's no longer a candidate. :)
>
> Two things we could do:
>
> * Vote on, and officially release, beta/alpha versions. (This comes with the overhead of the release procedure, and community fatigue of the voting/testing cycle.)
>
> * Set up easy-to-access nightlies. Link to them from a place on the dev section of the site, and make sure that people who we send there release that these are _not_ releases.
>
>
> On 17 May 2013 07:56, Nitin Mehta <Ni...@citrix.com> wrote:
>> +1.
>> Need the beta especially because folks would want to test early and
>> crossing the last mile can take a bit of time.
>> But hopefully its not too much of an overhead.
>>
>> Thanks,
>> -Nitin
>>
>> On 16/05/13 7:27 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
>>
>> >+1, perhaps I'm late to this thread, but this makes lot of sense.
>> >
>> >
>> >-------- Original message --------
>> >From: Pranav Saxena <pr...@citrix.com>
>> >Date:
>> >To: dev@cloudstack.apache.org,aemneina@gmail.com
>> >Subject: RE: [DISCUSS] Should we be releasing -beta releases?
>> >
>> >
>> >+1 to what Ahmad says here . Perfect reasoning .
>> >
>> >There have been many users on the list asking for some capability
>> >/feature present in CloudStack when it's actually under development in
>> >the current release. Beta release would allow them to get a feel of it .
>> >Definitely , it would help to further refine any new feature further when
>> >actually tested in a production environment .
>> >
>> >-----Original Message-----
>> >From: Ahmad Emneina [mailto:aemneina@gmail.com]
>> >Sent: Wednesday, May 15, 2013 12:07 AM
>> >To: dev@cloudstack.apache.org
>> >Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>> >
>> >+1
>> >I feel this allows for users who are chomping at the bit to get a hold of
>> >feature X. Tinker with feature X, expose bugs or use case issues well
>> >before an official release. Saves on the disappointment as well. ;)
>> >
>> >
>> >On Tue, May 14, 2013 at 9:34 AM, Chip Childers
>> ><ch...@sungard.com>wrote:
>> >
>> >> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
>> >> > Are you going to support upgrades from your Betas to release (and
>> >> > betaN to betaN+1)?
>> >> > If the answer is no, then there is no interest on my part. It's not
>> >> > better than us producing nightly builds, or highlighting jenkins
>> >> > builds.
>> >>
>> >> Perhaps doing a better job of highlighting nightly builds at key
>> >> moments is the right answer to the problem I was trying to solve (more
>> >> user testing of upgrades)?
>> >>
>> >> The beta idea comes with some overhead, and perhaps that overhead
>> >> isn't worth the benefit (if there are other ways to achieve that
>> >> goal). And that's why I floated the idea... to get reactions.
>> >>
>> >> >
>> >> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
>> >> > <ch...@sungard.com> wrote:
>> >> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
>> >> > >> As a relative outsider;
>> >> > >>
>> >> > >> any branch that is not released yet is a beta release. Why make
>> >> > >> it
>> >> more
>> >> > >> explicit. Wouldn't this add support burdon? Make a branch 'in beta'
>> >> and
>> >> > >> appoint a guard to make sure no new feartures but only fixes go
>> >> > >> in
>> >> (kind of
>> >> > >> how you are working right now)
>> >> > >
>> >> > > So we do that today. However, a "release" as a -beta will get
>> >> > > more
>> >> user
>> >> > > attention eariler in our release cycle (at least that's my
>> >> > > theory). We need that user attention to help us ensure that
>> >>upgrades work.
>> >> > >
>> >> > >>
>> >> > >> Daan
>> >> > >>
>> >> > >>
>> >> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net>
>> >> wrote:
>> >> > >>
>> >> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
>> >> > >> >
>> >> > >> > Yes to beta releases. I know that users could test at any time,
>> >> > >> > but
>> >> we
>> >> > >> > need explicit targets for users that say "now is a good time to
>> >> > >> > test this and give feedback."
>> >> > >> >
>> >> > >> > +1
>> >> > >> >
>> >> > >> >
>> >> > >> > Best,
>> >> > >> >
>> >> > >> > jzb
>> >> > >> > --
>> >> > >> > Joe Brockmeier
>> >> > >> > jzb@zonker.net
>> >> > >> > Twitter: @jzb
>> >> > >> > http://www.dissociatedpress.net/
>> >> > >> >
>> >> >
>> >>
>
>
>
> --
> NS
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Noah Slater <ns...@apache.org>.
We need to be careful about how we approach this. A "release" is something
that is voted on. A "release candidate" is something that is about to be
voted on. If you you don't vote on something, it's not a release. And if
you've voted on something, it's no longer a candidate. :)
Two things we could do:
* Vote on, and officially release, beta/alpha versions. (This comes with
the overhead of the release procedure, and community fatigue of the
voting/testing cycle.)
* Set up easy-to-access nightlies. Link to them from a place on the dev
section of the site, and make sure that people who we send there release
that these are _not_ releases.
On 17 May 2013 07:56, Nitin Mehta <Ni...@citrix.com> wrote:
> +1.
> Need the beta especially because folks would want to test early and
> crossing the last mile can take a bit of time.
> But hopefully its not too much of an overhead.
>
> Thanks,
> -Nitin
>
> On 16/05/13 7:27 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
>
> >+1, perhaps I'm late to this thread, but this makes lot of sense.
> >
> >
> >-------- Original message --------
> >From: Pranav Saxena <pr...@citrix.com>
> >Date:
> >To: dev@cloudstack.apache.org,aemneina@gmail.com
> >Subject: RE: [DISCUSS] Should we be releasing -beta releases?
> >
> >
> >+1 to what Ahmad says here . Perfect reasoning .
> >
> >There have been many users on the list asking for some capability
> >/feature present in CloudStack when it's actually under development in
> >the current release. Beta release would allow them to get a feel of it .
> >Definitely , it would help to further refine any new feature further when
> >actually tested in a production environment .
> >
> >-----Original Message-----
> >From: Ahmad Emneina [mailto:aemneina@gmail.com]
> >Sent: Wednesday, May 15, 2013 12:07 AM
> >To: dev@cloudstack.apache.org
> >Subject: Re: [DISCUSS] Should we be releasing -beta releases?
> >
> >+1
> >I feel this allows for users who are chomping at the bit to get a hold of
> >feature X. Tinker with feature X, expose bugs or use case issues well
> >before an official release. Saves on the disappointment as well. ;)
> >
> >
> >On Tue, May 14, 2013 at 9:34 AM, Chip Childers
> ><ch...@sungard.com>wrote:
> >
> >> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> >> > Are you going to support upgrades from your Betas to release (and
> >> > betaN to betaN+1)?
> >> > If the answer is no, then there is no interest on my part. It's not
> >> > better than us producing nightly builds, or highlighting jenkins
> >> > builds.
> >>
> >> Perhaps doing a better job of highlighting nightly builds at key
> >> moments is the right answer to the problem I was trying to solve (more
> >> user testing of upgrades)?
> >>
> >> The beta idea comes with some overhead, and perhaps that overhead
> >> isn't worth the benefit (if there are other ways to achieve that
> >> goal). And that's why I floated the idea... to get reactions.
> >>
> >> >
> >> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> >> > <ch...@sungard.com> wrote:
> >> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> >> > >> As a relative outsider;
> >> > >>
> >> > >> any branch that is not released yet is a beta release. Why make
> >> > >> it
> >> more
> >> > >> explicit. Wouldn't this add support burdon? Make a branch 'in beta'
> >> and
> >> > >> appoint a guard to make sure no new feartures but only fixes go
> >> > >> in
> >> (kind of
> >> > >> how you are working right now)
> >> > >
> >> > > So we do that today. However, a "release" as a -beta will get
> >> > > more
> >> user
> >> > > attention eariler in our release cycle (at least that's my
> >> > > theory). We need that user attention to help us ensure that
> >>upgrades work.
> >> > >
> >> > >>
> >> > >> Daan
> >> > >>
> >> > >>
> >> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net>
> >> wrote:
> >> > >>
> >> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> >> > >> >
> >> > >> > Yes to beta releases. I know that users could test at any time,
> >> > >> > but
> >> we
> >> > >> > need explicit targets for users that say "now is a good time to
> >> > >> > test this and give feedback."
> >> > >> >
> >> > >> > +1
> >> > >> >
> >> > >> >
> >> > >> > Best,
> >> > >> >
> >> > >> > jzb
> >> > >> > --
> >> > >> > Joe Brockmeier
> >> > >> > jzb@zonker.net
> >> > >> > Twitter: @jzb
> >> > >> > http://www.dissociatedpress.net/
> >> > >> >
> >> >
> >>
>
>
--
NS
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nitin Mehta <Ni...@citrix.com>.
+1.
Need the beta especially because folks would want to test early and
crossing the last mile can take a bit of time.
But hopefully its not too much of an overhead.
Thanks,
-Nitin
On 16/05/13 7:27 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
>+1, perhaps I'm late to this thread, but this makes lot of sense.
>
>
>-------- Original message --------
>From: Pranav Saxena <pr...@citrix.com>
>Date:
>To: dev@cloudstack.apache.org,aemneina@gmail.com
>Subject: RE: [DISCUSS] Should we be releasing -beta releases?
>
>
>+1 to what Ahmad says here . Perfect reasoning .
>
>There have been many users on the list asking for some capability
>/feature present in CloudStack when it's actually under development in
>the current release. Beta release would allow them to get a feel of it .
>Definitely , it would help to further refine any new feature further when
>actually tested in a production environment .
>
>-----Original Message-----
>From: Ahmad Emneina [mailto:aemneina@gmail.com]
>Sent: Wednesday, May 15, 2013 12:07 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>
>+1
>I feel this allows for users who are chomping at the bit to get a hold of
>feature X. Tinker with feature X, expose bugs or use case issues well
>before an official release. Saves on the disappointment as well. ;)
>
>
>On Tue, May 14, 2013 at 9:34 AM, Chip Childers
><ch...@sungard.com>wrote:
>
>> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
>> > Are you going to support upgrades from your Betas to release (and
>> > betaN to betaN+1)?
>> > If the answer is no, then there is no interest on my part. It's not
>> > better than us producing nightly builds, or highlighting jenkins
>> > builds.
>>
>> Perhaps doing a better job of highlighting nightly builds at key
>> moments is the right answer to the problem I was trying to solve (more
>> user testing of upgrades)?
>>
>> The beta idea comes with some overhead, and perhaps that overhead
>> isn't worth the benefit (if there are other ways to achieve that
>> goal). And that's why I floated the idea... to get reactions.
>>
>> >
>> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
>> > <ch...@sungard.com> wrote:
>> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
>> > >> As a relative outsider;
>> > >>
>> > >> any branch that is not released yet is a beta release. Why make
>> > >> it
>> more
>> > >> explicit. Wouldn't this add support burdon? Make a branch 'in beta'
>> and
>> > >> appoint a guard to make sure no new feartures but only fixes go
>> > >> in
>> (kind of
>> > >> how you are working right now)
>> > >
>> > > So we do that today. However, a "release" as a -beta will get
>> > > more
>> user
>> > > attention eariler in our release cycle (at least that's my
>> > > theory). We need that user attention to help us ensure that
>>upgrades work.
>> > >
>> > >>
>> > >> Daan
>> > >>
>> > >>
>> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net>
>> wrote:
>> > >>
>> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
>> > >> >
>> > >> > Yes to beta releases. I know that users could test at any time,
>> > >> > but
>> we
>> > >> > need explicit targets for users that say "now is a good time to
>> > >> > test this and give feedback."
>> > >> >
>> > >> > +1
>> > >> >
>> > >> >
>> > >> > Best,
>> > >> >
>> > >> > jzb
>> > >> > --
>> > >> > Joe Brockmeier
>> > >> > jzb@zonker.net
>> > >> > Twitter: @jzb
>> > >> > http://www.dissociatedpress.net/
>> > >> >
>> >
>>
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by "Musayev, Ilya" <im...@webmd.net>.
+1, perhaps I'm late to this thread, but this makes lot of sense.
-------- Original message --------
From: Pranav Saxena <pr...@citrix.com>
Date:
To: dev@cloudstack.apache.org,aemneina@gmail.com
Subject: RE: [DISCUSS] Should we be releasing -beta releases?
+1 to what Ahmad says here . Perfect reasoning .
There have been many users on the list asking for some capability /feature present in CloudStack when it's actually under development in the current release. Beta release would allow them to get a feel of it . Definitely , it would help to further refine any new feature further when actually tested in a production environment .
-----Original Message-----
From: Ahmad Emneina [mailto:aemneina@gmail.com]
Sent: Wednesday, May 15, 2013 12:07 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Should we be releasing -beta releases?
+1
I feel this allows for users who are chomping at the bit to get a hold of feature X. Tinker with feature X, expose bugs or use case issues well before an official release. Saves on the disappointment as well. ;)
On Tue, May 14, 2013 at 9:34 AM, Chip Childers <ch...@sungard.com>wrote:
> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> > Are you going to support upgrades from your Betas to release (and
> > betaN to betaN+1)?
> > If the answer is no, then there is no interest on my part. It's not
> > better than us producing nightly builds, or highlighting jenkins
> > builds.
>
> Perhaps doing a better job of highlighting nightly builds at key
> moments is the right answer to the problem I was trying to solve (more
> user testing of upgrades)?
>
> The beta idea comes with some overhead, and perhaps that overhead
> isn't worth the benefit (if there are other ways to achieve that
> goal). And that's why I floated the idea... to get reactions.
>
> >
> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> > <ch...@sungard.com> wrote:
> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> > >> As a relative outsider;
> > >>
> > >> any branch that is not released yet is a beta release. Why make
> > >> it
> more
> > >> explicit. Wouldn't this add support burdon? Make a branch 'in beta'
> and
> > >> appoint a guard to make sure no new feartures but only fixes go
> > >> in
> (kind of
> > >> how you are working right now)
> > >
> > > So we do that today. However, a "release" as a -beta will get
> > > more
> user
> > > attention eariler in our release cycle (at least that's my
> > > theory). We need that user attention to help us ensure that upgrades work.
> > >
> > >>
> > >> Daan
> > >>
> > >>
> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net>
> wrote:
> > >>
> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> > >> >
> > >> > Yes to beta releases. I know that users could test at any time,
> > >> > but
> we
> > >> > need explicit targets for users that say "now is a good time to
> > >> > test this and give feedback."
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> > Best,
> > >> >
> > >> > jzb
> > >> > --
> > >> > Joe Brockmeier
> > >> > jzb@zonker.net
> > >> > Twitter: @jzb
> > >> > http://www.dissociatedpress.net/
> > >> >
> >
>
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by Pranav Saxena <pr...@citrix.com>.
+1 to what Ahmad says here . Perfect reasoning .
There have been many users on the list asking for some capability /feature present in CloudStack when it's actually under development in the current release. Beta release would allow them to get a feel of it . Definitely , it would help to further refine any new feature further when actually tested in a production environment .
-----Original Message-----
From: Ahmad Emneina [mailto:aemneina@gmail.com]
Sent: Wednesday, May 15, 2013 12:07 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Should we be releasing -beta releases?
+1
I feel this allows for users who are chomping at the bit to get a hold of feature X. Tinker with feature X, expose bugs or use case issues well before an official release. Saves on the disappointment as well. ;)
On Tue, May 14, 2013 at 9:34 AM, Chip Childers <ch...@sungard.com>wrote:
> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> > Are you going to support upgrades from your Betas to release (and
> > betaN to betaN+1)?
> > If the answer is no, then there is no interest on my part. It's not
> > better than us producing nightly builds, or highlighting jenkins
> > builds.
>
> Perhaps doing a better job of highlighting nightly builds at key
> moments is the right answer to the problem I was trying to solve (more
> user testing of upgrades)?
>
> The beta idea comes with some overhead, and perhaps that overhead
> isn't worth the benefit (if there are other ways to achieve that
> goal). And that's why I floated the idea... to get reactions.
>
> >
> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> > <ch...@sungard.com> wrote:
> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> > >> As a relative outsider;
> > >>
> > >> any branch that is not released yet is a beta release. Why make
> > >> it
> more
> > >> explicit. Wouldn't this add support burdon? Make a branch 'in beta'
> and
> > >> appoint a guard to make sure no new feartures but only fixes go
> > >> in
> (kind of
> > >> how you are working right now)
> > >
> > > So we do that today. However, a "release" as a -beta will get
> > > more
> user
> > > attention eariler in our release cycle (at least that's my
> > > theory). We need that user attention to help us ensure that upgrades work.
> > >
> > >>
> > >> Daan
> > >>
> > >>
> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net>
> wrote:
> > >>
> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> > >> >
> > >> > Yes to beta releases. I know that users could test at any time,
> > >> > but
> we
> > >> > need explicit targets for users that say "now is a good time to
> > >> > test this and give feedback."
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> > Best,
> > >> >
> > >> > jzb
> > >> > --
> > >> > Joe Brockmeier
> > >> > jzb@zonker.net
> > >> > Twitter: @jzb
> > >> > http://www.dissociatedpress.net/
> > >> >
> >
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Ahmad Emneina <ae...@gmail.com>.
+1
I feel this allows for users who are chomping at the bit to get a hold of
feature X. Tinker with feature X, expose bugs or use case issues well
before an official release. Saves on the disappointment as well. ;)
On Tue, May 14, 2013 at 9:34 AM, Chip Childers <ch...@sungard.com>wrote:
> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> > Are you going to support upgrades from your Betas to release (and
> > betaN to betaN+1)?
> > If the answer is no, then there is no interest on my part. It's not
> > better than us producing nightly builds, or highlighting jenkins
> > builds.
>
> Perhaps doing a better job of highlighting nightly builds at key moments
> is the right answer to the problem I was trying to solve (more user
> testing of upgrades)?
>
> The beta idea comes with some overhead, and perhaps that overhead isn't
> worth the benefit (if there are other ways to achieve that goal). And
> that's why I floated the idea... to get reactions.
>
> >
> > On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> > <ch...@sungard.com> wrote:
> > > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> > >> As a relative outsider;
> > >>
> > >> any branch that is not released yet is a beta release. Why make it
> more
> > >> explicit. Wouldn't this add support burdon? Make a branch 'in beta'
> and
> > >> appoint a guard to make sure no new feartures but only fixes go in
> (kind of
> > >> how you are working right now)
> > >
> > > So we do that today. However, a "release" as a -beta will get more
> user
> > > attention eariler in our release cycle (at least that's my theory). We
> > > need that user attention to help us ensure that upgrades work.
> > >
> > >>
> > >> Daan
> > >>
> > >>
> > >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net>
> wrote:
> > >>
> > >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> > >> >
> > >> > Yes to beta releases. I know that users could test at any time, but
> we
> > >> > need explicit targets for users that say "now is a good time to test
> > >> > this and give feedback."
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> > Best,
> > >> >
> > >> > jzb
> > >> > --
> > >> > Joe Brockmeier
> > >> > jzb@zonker.net
> > >> > Twitter: @jzb
> > >> > http://www.dissociatedpress.net/
> > >> >
> >
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Sebastien Goasguen <ru...@gmail.com>.
On May 14, 2013, at 12:34 PM, Chip Childers <ch...@sungard.com> wrote:
> On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
>> Are you going to support upgrades from your Betas to release (and
>> betaN to betaN+1)?
>> If the answer is no, then there is no interest on my part. It's not
>> better than us producing nightly builds, or highlighting jenkins
>> builds.
>
> Perhaps doing a better job of highlighting nightly builds at key moments
> is the right answer to the problem I was trying to solve (more user
> testing of upgrades)?
+1 on this, IMHO it's more of a documentation and delivery issue. If users knew where to find the latest rpm and debs they would test early.
In the download section we could have a "nightly build" section
And by the way we should send this type of thread to users...
-sebastien
>
> The beta idea comes with some overhead, and perhaps that overhead isn't
> worth the benefit (if there are other ways to achieve that goal). And
> that's why I floated the idea... to get reactions.
>
>>
>> On Tue, May 14, 2013 at 11:03 AM, Chip Childers
>> <ch...@sungard.com> wrote:
>>> On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
>>>> As a relative outsider;
>>>>
>>>> any branch that is not released yet is a beta release. Why make it more
>>>> explicit. Wouldn't this add support burdon? Make a branch 'in beta' and
>>>> appoint a guard to make sure no new feartures but only fixes go in (kind of
>>>> how you are working right now)
>>>
>>> So we do that today. However, a "release" as a -beta will get more user
>>> attention eariler in our release cycle (at least that's my theory). We
>>> need that user attention to help us ensure that upgrades work.
>>>
>>>>
>>>> Daan
>>>>
>>>>
>>>> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net> wrote:
>>>>
>>>>> On Tue, May 14, 2013, at 09:41 AM, 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?
>>>>>
>>>>> Yes to beta releases. I know that users could test at any time, but we
>>>>> need explicit targets for users that say "now is a good time to test
>>>>> this and give feedback."
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> jzb
>>>>> --
>>>>> Joe Brockmeier
>>>>> jzb@zonker.net
>>>>> Twitter: @jzb
>>>>> http://www.dissociatedpress.net/
>>>>>
>>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Chip Childers <ch...@sungard.com>.
On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote:
> Are you going to support upgrades from your Betas to release (and
> betaN to betaN+1)?
> If the answer is no, then there is no interest on my part. It's not
> better than us producing nightly builds, or highlighting jenkins
> builds.
Perhaps doing a better job of highlighting nightly builds at key moments
is the right answer to the problem I was trying to solve (more user
testing of upgrades)?
The beta idea comes with some overhead, and perhaps that overhead isn't
worth the benefit (if there are other ways to achieve that goal). And
that's why I floated the idea... to get reactions.
>
> On Tue, May 14, 2013 at 11:03 AM, Chip Childers
> <ch...@sungard.com> wrote:
> > On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> >> As a relative outsider;
> >>
> >> any branch that is not released yet is a beta release. Why make it more
> >> explicit. Wouldn't this add support burdon? Make a branch 'in beta' and
> >> appoint a guard to make sure no new feartures but only fixes go in (kind of
> >> how you are working right now)
> >
> > So we do that today. However, a "release" as a -beta will get more user
> > attention eariler in our release cycle (at least that's my theory). We
> > need that user attention to help us ensure that upgrades work.
> >
> >>
> >> Daan
> >>
> >>
> >> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net> wrote:
> >>
> >> > On Tue, May 14, 2013, at 09:41 AM, 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?
> >> >
> >> > Yes to beta releases. I know that users could test at any time, but we
> >> > need explicit targets for users that say "now is a good time to test
> >> > this and give feedback."
> >> >
> >> > +1
> >> >
> >> >
> >> > Best,
> >> >
> >> > jzb
> >> > --
> >> > Joe Brockmeier
> >> > jzb@zonker.net
> >> > Twitter: @jzb
> >> > http://www.dissociatedpress.net/
> >> >
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Joe Brockmeier <jz...@zonker.net>.
On Tue, May 14, 2013, at 10:59 AM, David Nalley wrote:
> Are you going to support upgrades from your Betas to release (and
> betaN to betaN+1)?
> If the answer is no, then there is no interest on my part. It's not
> better than us producing nightly builds, or highlighting jenkins
> builds.
The problem with the nightly builds is that there's no signal to the
larger community of "OK, seriously - we need you to start testing NOW."
And presenting people with "pick any build" is a losing proposition.
We need to be able to:
1) Signal that we're ready for a larger community to start testing
because - while we know it's not perfect, we also need to find blockers
that we don't already know about.
2) Engage folks who are less connected to the day-to-day development
process and provide a well-defined process and point them at an artifact
we're prepared to see a lot of bug reports against.
3) Promote the process and be ready to help a larger body of community
members who will likely need guidance in filing bugs, etc.
I'm indifferent to upgrades between betas or to production release. I
think it's a nice to have, but I don't anticipate anyone using betas in
production, or even starting a production deployment with a beta.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by David Nalley <da...@gnsa.us>.
Are you going to support upgrades from your Betas to release (and
betaN to betaN+1)?
If the answer is no, then there is no interest on my part. It's not
better than us producing nightly builds, or highlighting jenkins
builds.
On Tue, May 14, 2013 at 11:03 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
>> As a relative outsider;
>>
>> any branch that is not released yet is a beta release. Why make it more
>> explicit. Wouldn't this add support burdon? Make a branch 'in beta' and
>> appoint a guard to make sure no new feartures but only fixes go in (kind of
>> how you are working right now)
>
> So we do that today. However, a "release" as a -beta will get more user
> attention eariler in our release cycle (at least that's my theory). We
> need that user attention to help us ensure that upgrades work.
>
>>
>> Daan
>>
>>
>> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net> wrote:
>>
>> > On Tue, May 14, 2013, at 09:41 AM, 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?
>> >
>> > Yes to beta releases. I know that users could test at any time, but we
>> > need explicit targets for users that say "now is a good time to test
>> > this and give feedback."
>> >
>> > +1
>> >
>> >
>> > Best,
>> >
>> > jzb
>> > --
>> > Joe Brockmeier
>> > jzb@zonker.net
>> > Twitter: @jzb
>> > http://www.dissociatedpress.net/
>> >
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Chip Childers <ch...@sungard.com>.
On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote:
> As a relative outsider;
>
> any branch that is not released yet is a beta release. Why make it more
> explicit. Wouldn't this add support burdon? Make a branch 'in beta' and
> appoint a guard to make sure no new feartures but only fixes go in (kind of
> how you are working right now)
So we do that today. However, a "release" as a -beta will get more user
attention eariler in our release cycle (at least that's my theory). We
need that user attention to help us ensure that upgrades work.
>
> Daan
>
>
> On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net> wrote:
>
> > On Tue, May 14, 2013, at 09:41 AM, 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?
> >
> > Yes to beta releases. I know that users could test at any time, but we
> > need explicit targets for users that say "now is a good time to test
> > this and give feedback."
> >
> > +1
> >
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > jzb@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> >
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
As a relative outsider;
any branch that is not released yet is a beta release. Why make it more
explicit. Wouldn't this add support burdon? Make a branch 'in beta' and
appoint a guard to make sure no new feartures but only fixes go in (kind of
how you are working right now)
Daan
On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier <jz...@zonker.net> wrote:
> On Tue, May 14, 2013, at 09:41 AM, 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?
>
> Yes to beta releases. I know that users could test at any time, but we
> need explicit targets for users that say "now is a good time to test
> this and give feedback."
>
> +1
>
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by Giles Sirett <gi...@shapeblue.com>.
+1
It would be much easier for planning purposes if we had target dates for betas.
That would allow us to say to our user community "hey, we've got something new for you to test, come and get it" - instead of people having to stay up to date with the development and then choose when to start to test
Noticed Daan's point about the overhead & burdon, which is true, but I still think it would be better this way
Kind Regards
Giles
D: +44 20 3603 0541 | M: +44 796 111 2055
Giles.Sirett@shapeblue.com
-----Original Message-----
From: Joe Brockmeier [mailto:jzb@zonker.net]
Sent: 14 May 2013 15:49
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Should we be releasing -beta releases?
On Tue, May 14, 2013, at 09:41 AM, 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?
Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say "now is a good time to test this and give feedback."
+1
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Joe Brockmeier <jz...@zonker.net>.
On Tue, May 14, 2013, at 09:41 AM, 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?
Yes to beta releases. I know that users could test at any time, but we
need explicit targets for users that say "now is a good time to test
this and give feedback."
+1
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
:} it is due to master moving faster then me being all over the code.
I have ported it once again to master and am busy testing again. but
we need it and have just moved to 4.1.1. I agree with you Alex. So we
will not release our fork just the patch via the earliest main
release. (I could publish a 4.1.1 patch however)
On Thu, Aug 1, 2013 at 7:00 PM, Alex Huang <Al...@citrix.com> wrote:
> +1
>
> If it's due to company specific issues (licensing or company secret). Maybe we can propose a plugin interface for it and see if you can keep just that code private.
>
> Just look at how much master have changed from 4.2. If we can we should try not to fork on the core code in cloudstack. Maintaining will be tough.
>
> --Alex
>
>> -----Original Message-----
>> From: Musayev, Ilya [mailto:imusayev@webmd.net]
>> Sent: Thursday, August 1, 2013 9:51 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [DISCUSS] Should we be releasing -beta releases?
>>
>> Daan and Hugo,
>>
>> This is just my opinion, you should consider merging this feature into master
>> when time allows - this way you don't have to maintain a private branch of
>> ACS in the future. Just my two cents :)
>>
>> Regards
>> ilya
>>
>> > -----Original Message-----
>> > From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> > Sent: Thursday, August 01, 2013 4:13 AM
>> > To: dev
>> > Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>> >
>> > On Thu, Aug 1, 2013 at 12:46 AM, Musayev, Ilya <im...@webmd.net>
>> > wrote:
>> > > The reason why CloudSand was created, was to bring in urgently
>> > > needed
>> > features into stable version, such that on the next major upgrade to
>> > ACS, all features work as expected and nothing should break.
>> > This is the same that we have done. Except that we have put work into
>> > CLOUDSTACK-1532 that was urgently needed internally at Schuberg
>> > Philis. It is implemented in 4.1.1-SBP a private release. I have
>> > ported it to master several times but testing and paralel development
>> > on other network features have prevented it from being merged in master.
>> >
>> > > What features are we talking about?
>> >
>> > I gues our focus is hastening our own development and not backporting.
>> >
>> > regards,
>> > Daan
>>
>
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by Alex Huang <Al...@citrix.com>.
+1
If it's due to company specific issues (licensing or company secret). Maybe we can propose a plugin interface for it and see if you can keep just that code private.
Just look at how much master have changed from 4.2. If we can we should try not to fork on the core code in cloudstack. Maintaining will be tough.
--Alex
> -----Original Message-----
> From: Musayev, Ilya [mailto:imusayev@webmd.net]
> Sent: Thursday, August 1, 2013 9:51 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Should we be releasing -beta releases?
>
> Daan and Hugo,
>
> This is just my opinion, you should consider merging this feature into master
> when time allows - this way you don't have to maintain a private branch of
> ACS in the future. Just my two cents :)
>
> Regards
> ilya
>
> > -----Original Message-----
> > From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> > Sent: Thursday, August 01, 2013 4:13 AM
> > To: dev
> > Subject: Re: [DISCUSS] Should we be releasing -beta releases?
> >
> > On Thu, Aug 1, 2013 at 12:46 AM, Musayev, Ilya <im...@webmd.net>
> > wrote:
> > > The reason why CloudSand was created, was to bring in urgently
> > > needed
> > features into stable version, such that on the next major upgrade to
> > ACS, all features work as expected and nothing should break.
> > This is the same that we have done. Except that we have put work into
> > CLOUDSTACK-1532 that was urgently needed internally at Schuberg
> > Philis. It is implemented in 4.1.1-SBP a private release. I have
> > ported it to master several times but testing and paralel development
> > on other network features have prevented it from being merged in master.
> >
> > > What features are we talking about?
> >
> > I gues our focus is hastening our own development and not backporting.
> >
> > regards,
> > Daan
>
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by "Musayev, Ilya" <im...@webmd.net>.
Daan and Hugo,
This is just my opinion, you should consider merging this feature into master when time allows - this way you don't have to maintain a private branch of ACS in the future. Just my two cents :)
Regards
ilya
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Thursday, August 01, 2013 4:13 AM
> To: dev
> Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>
> On Thu, Aug 1, 2013 at 12:46 AM, Musayev, Ilya <im...@webmd.net>
> wrote:
> > The reason why CloudSand was created, was to bring in urgently needed
> features into stable version, such that on the next major upgrade to ACS, all
> features work as expected and nothing should break.
> This is the same that we have done. Except that we have put work into
> CLOUDSTACK-1532 that was urgently needed internally at Schuberg Philis. It
> is implemented in 4.1.1-SBP a private release. I have ported it to master
> several times but testing and paralel development on other network
> features have prevented it from being merged in master.
>
> > What features are we talking about?
>
> I gues our focus is hastening our own development and not backporting.
>
> regards,
> Daan
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
On Thu, Aug 1, 2013 at 12:46 AM, Musayev, Ilya <im...@webmd.net> wrote:
> The reason why CloudSand was created, was to bring in urgently needed features into stable version, such that on the next major upgrade to ACS, all features work as expected and nothing should break.
This is the same that we have done. Except that we have put work into
CLOUDSTACK-1532 that was urgently needed internally at Schuberg
Philis. It is implemented in 4.1.1-SBP a private release. I have
ported it to master several times but testing and paralel development
on other network features have prevented it from being merged in
master.
> What features are we talking about?
I gues our focus is hastening our own development and not backporting.
regards,
Daan
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by "Musayev, Ilya" <im...@webmd.net>.
Daan,
Why can't the patch be committed to master?
The reason why CloudSand was created, was to bring in urgently needed features into stable version, such that on the next major upgrade to ACS, all features work as expected and nothing should break.
Example, if I have a feature in CloudSand 4.1 that was backported from ACS 4.2, when end user upgrades to stable release of ACS4.2 - it should all function as expected.
So backward compatibility is one of the main focuses for CloudSand release.
What features are we talking about?
Regards
ilya
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Wednesday, July 31, 2013 3:20 PM
> To: dev
> Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>
> H Ilya,
>
> I am working on a paralel track. At Schuberg Philis we have a version that
> contains some code from 4.2 and a patch that I cannot get committed to
> master. I don't want to release this in the open, but am interested in your
> considerations on the subject.
>
> regards,
> Daan
>
> On Wed, Jul 31, 2013 at 5:55 PM, Musayev, Ilya <im...@webmd.net>
> wrote:
> > Oops, wrong url for github, correct url is:
> >
> > http://www.guthub.com/serverchief/cloudsand
> >
> >> -----Original Message-----
> >> From: Musayev, Ilya [mailto:imusayev@webmd.net]
> >> Sent: Wednesday, July 31, 2013 11:52 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [DISCUSS] Should we be releasing -beta releases?
> >>
> >> I run my own hybrid version of 4.1 and with some features of 4.2 in
> >> production, since - I needed to backport some features of 4.2 into
> >> 4.1
> >>
> >> Since this version was not officially released under ACS, I branded
> >> it as CloudSand (powered by Apache CloudStack).
> >>
> >> You can see the code here:
> >> http://www.guthub.com/serverchief.com/cloudsand | www.
> >> Cloudsand.com
> >>
> >> At some point, I would like to release a "RC/beta" of CloudSand 4.2
> >> on my own, if anyone wants to join the effort, please ping me :)
> >>
> >> Thanks
> >> Ilya
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Nux! [mailto:nux@li.nux.ro]
> >> > Sent: Thursday, June 27, 2013 8:06 AM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: Re: [DISCUSS] Should we be releasing -beta releases?
> >> >
> >> > On 14.05.2013 15:41, 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
> >> >
> >> > +1 for beta releases, I was actually thinking of building some RPMS
> >> > from source, want to get a flavour of 4.2 features, but not sure if
> >> > I can be bothered with that. If I had some nightlies or betas
> >> > available on cloudstack.apt-get.eu I'd definitely give it a go.
> >> >
> >> > Lucian
> >> >
> >> > --
> >> > Sent from the Delta quadrant using Borg technology!
> >> >
> >> > Nux!
> >> > www.nux.ro
> >
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
H Ilya,
I am working on a paralel track. At Schuberg Philis we have a version
that contains some code from 4.2 and a patch that I cannot get
committed to master. I don't want to release this in the open, but am
interested in your considerations on the subject.
regards,
Daan
On Wed, Jul 31, 2013 at 5:55 PM, Musayev, Ilya <im...@webmd.net> wrote:
> Oops, wrong url for github, correct url is:
>
> http://www.guthub.com/serverchief/cloudsand
>
>> -----Original Message-----
>> From: Musayev, Ilya [mailto:imusayev@webmd.net]
>> Sent: Wednesday, July 31, 2013 11:52 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [DISCUSS] Should we be releasing -beta releases?
>>
>> I run my own hybrid version of 4.1 and with some features of 4.2 in
>> production, since - I needed to backport some features of 4.2 into 4.1
>>
>> Since this version was not officially released under ACS, I branded it as
>> CloudSand (powered by Apache CloudStack).
>>
>> You can see the code here:
>> http://www.guthub.com/serverchief.com/cloudsand | www.
>> Cloudsand.com
>>
>> At some point, I would like to release a "RC/beta" of CloudSand 4.2 on my
>> own, if anyone wants to join the effort, please ping me :)
>>
>> Thanks
>> Ilya
>>
>>
>>
>> > -----Original Message-----
>> > From: Nux! [mailto:nux@li.nux.ro]
>> > Sent: Thursday, June 27, 2013 8:06 AM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>> >
>> > On 14.05.2013 15:41, 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
>> >
>> > +1 for beta releases, I was actually thinking of building some RPMS
>> > from source, want to get a flavour of 4.2 features, but not sure if I
>> > can be bothered with that. If I had some nightlies or betas available
>> > on cloudstack.apt-get.eu I'd definitely give it a go.
>> >
>> > Lucian
>> >
>> > --
>> > Sent from the Delta quadrant using Borg technology!
>> >
>> > Nux!
>> > www.nux.ro
>
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by "Musayev, Ilya" <im...@webmd.net>.
Oops, wrong url for github, correct url is:
http://www.guthub.com/serverchief/cloudsand
> -----Original Message-----
> From: Musayev, Ilya [mailto:imusayev@webmd.net]
> Sent: Wednesday, July 31, 2013 11:52 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Should we be releasing -beta releases?
>
> I run my own hybrid version of 4.1 and with some features of 4.2 in
> production, since - I needed to backport some features of 4.2 into 4.1
>
> Since this version was not officially released under ACS, I branded it as
> CloudSand (powered by Apache CloudStack).
>
> You can see the code here:
> http://www.guthub.com/serverchief.com/cloudsand | www.
> Cloudsand.com
>
> At some point, I would like to release a "RC/beta" of CloudSand 4.2 on my
> own, if anyone wants to join the effort, please ping me :)
>
> Thanks
> Ilya
>
>
>
> > -----Original Message-----
> > From: Nux! [mailto:nux@li.nux.ro]
> > Sent: Thursday, June 27, 2013 8:06 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Should we be releasing -beta releases?
> >
> > On 14.05.2013 15:41, 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
> >
> > +1 for beta releases, I was actually thinking of building some RPMS
> > from source, want to get a flavour of 4.2 features, but not sure if I
> > can be bothered with that. If I had some nightlies or betas available
> > on cloudstack.apt-get.eu I'd definitely give it a go.
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
RE: [DISCUSS] Should we be releasing -beta releases?
Posted by "Musayev, Ilya" <im...@webmd.net>.
I run my own hybrid version of 4.1 and with some features of 4.2 in production, since - I needed to backport some features of 4.2 into 4.1
Since this version was not officially released under ACS, I branded it as CloudSand (powered by Apache CloudStack).
You can see the code here: http://www.guthub.com/serverchief.com/cloudsand | www. Cloudsand.com
At some point, I would like to release a "RC/beta" of CloudSand 4.2 on my own, if anyone wants to join the effort, please ping me :)
Thanks
Ilya
> -----Original Message-----
> From: Nux! [mailto:nux@li.nux.ro]
> Sent: Thursday, June 27, 2013 8:06 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Should we be releasing -beta releases?
>
> On 14.05.2013 15:41, 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
>
> +1 for beta releases, I was actually thinking of building some RPMS
> from source, want to get a flavour of 4.2 features, but not sure if I can be
> bothered with that. If I had some nightlies or betas available on
> cloudstack.apt-get.eu I'd definitely give it a go.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nux! <nu...@li.nux.ro>.
On 14.05.2013 15:41, 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
+1 for beta releases, I was actually thinking of building some RPMS
from source, want to get a flavour of 4.2 features, but not sure if I
can be bothered with that. If I had some nightlies or betas available on
cloudstack.apt-get.eu I'd definitely give it a go.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Noah Slater <ns...@apache.org>.
Yep! Welcome!
On 28 May 2013 22:56, Daan Hoogland <da...@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 <ns...@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 <da...@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 <ns...@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 <ru...@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
> >
>
--
NS
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
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 <ns...@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 <da...@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 <ns...@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 <ru...@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
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Chip Childers <ch...@sungard.com>.
On Tue, May 28, 2013 at 10:43:46PM +0100, Noah Slater 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@.
I'll write it that way next time.
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Noah Slater <ns...@apache.org>.
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 <da...@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 <ns...@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 <ru...@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
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
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 <ru...@gmail.com>wrote:
>
> On May 28, 2013, at 2:36 PM, Noah Slater <ns...@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 <ru...@gmail.com> wrote:
> >
> >>
> >> On May 24, 2013, at 12:26 PM, Chip Childers <ch...@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
>
>
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Sebastien Goasguen <ru...@gmail.com>.
On May 28, 2013, at 2:36 PM, Noah Slater <ns...@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 <ru...@gmail.com> wrote:
>
>>
>> On May 24, 2013, at 12:26 PM, Chip Childers <ch...@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
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Noah Slater <ns...@apache.org>.
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.
* Or marketing@, private@, and security@
On 27 May 2013 08:53, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On May 24, 2013, at 12:26 PM, Chip Childers <ch...@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
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Sebastien Goasguen <ru...@gmail.com>.
On May 24, 2013, at 12:26 PM, Chip Childers <ch...@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.
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Chip Childers <ch...@sungard.com>.
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. 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.
Shout if you disagree.
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nux! <nu...@li.nux.ro>.
On 05.08.2013 16:48, Daan Hoogland wrote:
> the 4.1 build for rhel63 says:
> Apache Cloudstack RHEL 6.3 packages
> This project is currently disabled
>
> this one didn't happen to be the one you where looking for? Anyway
> look at http://jenkins.cloudstack.org and browse around. I thought you
> would find them there.
Thanks, I'll have a look around there.
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
the 4.1 build for rhel63 says:
Apache Cloudstack RHEL 6.3 packages
This project is currently disabled
this one didn't happen to be the one you where looking for? Anyway
look at http://jenkins.cloudstack.org and browse around. I thought you
would find them there.
On Mon, Aug 5, 2013 at 5:40 PM, Daan Hoogland <da...@gmail.com> wrote:
> think was the keyword there, ... but I am looking for ya. moment
>
> On Mon, Aug 5, 2013 at 5:21 PM, Nux! <nu...@li.nux.ro> wrote:
>> On 05.08.2013 16:09, Daan Hoogland wrote:
>>>
>>> For this the jenkins builds might be suitable. I think if those are
>>> running on all active release branches.
>>
>>
>> Some URLs could be real handy now. :)
>>
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
think was the keyword there, ... but I am looking for ya. moment
On Mon, Aug 5, 2013 at 5:21 PM, Nux! <nu...@li.nux.ro> wrote:
> On 05.08.2013 16:09, Daan Hoogland wrote:
>>
>> For this the jenkins builds might be suitable. I think if those are
>> running on all active release branches.
>
>
> Some URLs could be real handy now. :)
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nux! <nu...@li.nux.ro>.
On 05.08.2013 16:09, Daan Hoogland wrote:
> For this the jenkins builds might be suitable. I think if those are
> running on all active release branches.
Some URLs could be real handy now. :)
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Daan Hoogland <da...@gmail.com>.
For this the jenkins builds might be suitable. I think if those are
running on all active release branches.
On Mon, Aug 5, 2013 at 4:42 PM, Nux! <nu...@li.nux.ro> wrote:
> On 31.07.2013 16:30, Chip Childers wrote:
>>
>> On Wed, Jul 31, 2013 at 12:04:50AM +0100, Nux! wrote:
>>>
>>> On 14.05.2013 15:41, 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?
>>>
>>>
>>> Hi,
>>>
>>> What has been decided? Will we see any 4.2 betas?
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>
>> I think that we realized that the upgrade support problems are
>> significant enough to make this difficult right now. Consider it an
>> aspiration for the future.
>
>
> To be honest even "unsupported" betas might be good. I'd be willing to test
> betas even without upgradability to "stable", just to see what to expect,
> what's new, what's good, what's bad etc.
> I'm sure there are many like me.
> Sure, I can download and build it myself, but it would've been much more
> convenient to have some RPMs on cloudstack.apt-get.eu; plus, not everyone is
> comfortable building RPMs or from source etc.
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nux! <nu...@li.nux.ro>.
On 31.07.2013 16:30, Chip Childers wrote:
> On Wed, Jul 31, 2013 at 12:04:50AM +0100, Nux! wrote:
>> On 14.05.2013 15:41, 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?
>>
>> Hi,
>>
>> What has been decided? Will we see any 4.2 betas?
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>
> I think that we realized that the upgrade support problems are
> significant enough to make this difficult right now. Consider it an
> aspiration for the future.
To be honest even "unsupported" betas might be good. I'd be willing to
test betas even without upgradability to "stable", just to see what to
expect, what's new, what's good, what's bad etc.
I'm sure there are many like me.
Sure, I can download and build it myself, but it would've been much
more convenient to have some RPMs on cloudstack.apt-get.eu; plus, not
everyone is comfortable building RPMs or from source etc.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Jul 31, 2013 at 12:04:50AM +0100, Nux! wrote:
> On 14.05.2013 15:41, 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?
>
> Hi,
>
> What has been decided? Will we see any 4.2 betas?
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
I think that we realized that the upgrade support problems are
significant enough to make this difficult right now. Consider it an
aspiration for the future.
Re: [DISCUSS] Should we be releasing -beta releases?
Posted by Nux! <nu...@li.nux.ro>.
On 14.05.2013 15:41, 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?
Hi,
What has been decided? Will we see any 4.2 betas?
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro