If there is a group of users in dire need for a specific feature they can 
always take the code and use it. No need to wait for an official release. 
Official release should adhere to quality guidelines (at least in terms of any 
reported regressions) even if it means release getting delayed.


On 05-Aug-2015, at 2:39 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:

> Yes we can if there is a group of users that don't use it but are in
> dire need far another feature. We just have to document and market it
> properly
> 
> On Tue, Aug 4, 2015 at 6:48 PM, Ramanath Katru
> <ramanath.ka...@citrix.com> wrote:
>> Daan,
>> 
>> I beg to differ. This is very much a product issue. We cannot knowingly 
>> release with an existing/working functionality broken. Especially if it is 
>> one of the features that users expect to be there. Remote Access VPN is an 
>> example. Right now this functionality is broken.
>> 
>> Ram Katru
>> 
>> -----Original Message-----
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Tuesday, August 4, 2015 4:57 PM
>> To: dev <dev@cloudstack.apache.org>
>> Subject: Re: Revisit Process for creating Blocker bugs
>> 
>> Ram,
>> 
>> This is a marketing issue, not a release issue. making a release or 
>> marketing it to the general public are two different things.
>> 
>> Daan
>> 
>> On Tue, Aug 4, 2015 at 12:41 PM, Ramanath Katru <ramanath.ka...@citrix.com> 
>> wrote:
>>> While we can say if a bug doesn’t effect "majority" of current users, we 
>>> can go ahead and release, but we should also look at a product perspective 
>>> not just release perspective. There are some features that are important 
>>> for cloudstack as a product and these cannot be broken in a release. If we 
>>> do not evaluate from a product perspective, then we will be turning 
>>> potential new users away.
>>> 
>>> Ram Katru
>>> 
>>> -----Original Message-----
>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>> Sent: Tuesday, August 4, 2015 1:54 AM
>>> To: dev <dev@cloudstack.apache.org>
>>> Subject: Re: Revisit Process for creating Blocker bugs
>>> 
>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu
>>> <somesh.na...@citrix.com>
>>> wrote:
>>> 
>>>> I would like to add that while the # of users affected is definitely
>>>> a major factor when ascertaining severity of an issue, should we not
>>>> consider the technical scope and/or use-case of a defect. For
>>>> example, let's say there is only one user using basic zone setup with
>>>> VMware in the community but the bug/regression has caused a major
>>>> failure like "No provisioning of VMs". Would this be considered a release 
>>>> blocker?
>>>> 
>>> 
>>> This is exactly the kind of discussion we need to have when such a case 
>>> comes by. For this as purely hypothetical case I would say, release. We can 
>>> not have other users abstain from badly needed features because one can not 
>>> share in the joy. We would have to release a fix for this afterwards.
>>> 
>>> just a 0.02 in virtual currency
>>> 
>>> 
>>> 
>>> --
>>> Daan
>> 
>> 
>> 
>> --
>> Daan
> 
> 
> 
> -- 
> Daan

Reply via email to