I think the purpose of this discussion is that there are people currently today
that are auto-assigning bugs to individual developers of the community. Most
of these bugs were assigned for two main reasons.
1. It was blatantly obvious the bugs stemmed from the feature developer.
- OR -
2. Th
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, April 15, 2013 7:22 AM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: Re: [ASFCS42] Proposed schedule for our next release
>
> On Thu, Apr 11, 2013 at 02:50:0
> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Thursday, April 18, 2013 6:41 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [ASFCS42] Proposed schedule for our next release
>
> On Thu, Apr 18, 2013 at 6:26 PM, Will Chan wrote:
&g
Again, I am not disputing that more features will make it in given Dave's
argument. In fact, I'm not really that keen on using the fixed cost of release
mgmt. for the reason of the move as well. Heck, I'm not even sure a 6 month
cycle would fix any of the issues that have already been outline
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, April 23, 2013 11:19 AM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: Re: [DISCUSS] ACS Release 4 month v/s 6 month
>
>
> How do you see the release schedu
Alena is right. They were introduced eons ago for customers to figure out
which objects still had pending jobs on them without having the need to know
the async job ID in the first place. I'm not sure who's using that now but if
you remove it, it may cause existing customers that do rely on th
+1 [Binding]
It looks like there are a couple of last minute features that would make 4.1 a
superb release. I would say that we should not allow any new features that
haven't already been proposed and that the extension does not go beyond 4
weeks. If beyond that, I'm a -1.
Will
> -Ori
