Wow. I think we need a consensus here. When a feature needs to be added, we go through proposals and a healthy discussion on whether the feature can be added or not. We need to do the same if an important feature support is to be removed. It cannot be a call to be made at the time of release and for the sake of making a release. We cannot pull the rug from underneath users. This is good way of losing confidence in a product open source or not.
Ram Katru -----Original Message----- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, August 5, 2015 2:40 AM To: dev <dev@cloudstack.apache.org> Subject: Re: Revisit Process for creating Blocker bugs 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
