Sudha, Animesh, You talk of process. No process will work unless it is executed on list. Setting priorities for a release candidate should therefor happen on list. What I propose is that a reporter always set their ticket to prio critical and then argues on list that it should be a blocker. This way people are aware of what blockers there are. As to your proposals Sudha:
- I don't think SLAs (should) mean anything to an opensource development community. setting them is a paper or even a digital tiger. However what you are saying is, if enforced, even more severe an intervention then my lowering of prios after one week. - I like your report proposal very much and would be very gratefull if you where to take this task. - publishing is already done in jira: https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12323265 We can clean up this dashboard some more but it has been functioning quite nicely for me. kind regards, Daan On Mon, May 26, 2014 at 8:53 PM, Animesh Chaturvedi <animesh.chaturv...@citrix.com> wrote: > Daan > > I concur with Sudha we should not change the priority of individual defects > without technical reasons. The outgoing defect rate is much lower for this > time of the release and certainly is a concern as you have raised. We should > publish daily list of blockers and ask for status update. > > You can also do bulk edit for open tickets and ask for updates, I will also > nudge a few folks here. > > thanks > Animesh > >> -----Original Message----- >> From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] >> Sent: Monday, May 26, 2014 9:21 AM >> To: dev@cloudstack.apache.org >> Subject: RE: [ACS44][PROPOSAL] old blocker bugs >> >> >> -1 on the proposal to lower priority of defects based on timeframe. These >> are blockers for features and some for release as well. We should not be >> modifying the priority of defect unless the original reporter or RM agrees to >> do so for technical reasons but not because these are not touched by >> anyone. As this is community based development environment, someone >> need to pick up and get the context and fix it which might be taking time. >> Understand that community should be aware of these blockers on daily >> basis and pick those up faster and fix them within reasonable SLAs. >> Unfortunately we do not have any SLAs. It is dangerous proposal to reduce >> priority without review of technical impact of the defect. >> >> Following process improvement would help to address this issue: >> >> - Set SLAs for a more streamlined approach towards addressing defects >> within reasonable timeframe. For eg blockers should be fixed within 24 >> hours, critical within 72 hours etc. >> - Send daily reports to ML on the blockers to provide more visibility (I can >> take up this task). >> - republish definition of defect priority so community is aware on the proper >> categorization of defects (I can publish this as well on wiki. >> >> Thanks >> /Sudha >> >> >> -----Original Message----- >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >> Sent: Monday, May 26, 2014 5:11 AM >> To: dev >> Subject: Re: [ACS44][PROPOSAL] old blocker bugs >> >> Not well formatted but is this what you want? >> >> Key Summary Reporter Assignee Updated >> CLOUDSTACK-6754 >> >> SSVM not responding with S3 secondary sotre >> >> Pavan Kumar Bandarupally Min Chen 26/May/14 Actions >> CLOUDSTACK-6755 >> >> [OVS] Can't create more than 7 GRE tunnel networks in xen cluster >> >> Sanjeev N Murali Reddy 23/May/14 >> Actions >> CLOUDSTACK-6623 >> >> Register template does not work as expected, when deploying simulator and >> xen zones simultaneously on a single management server. >> >> Bharat Kumar edison su 22/May/14 >> Actions >> CLOUDSTACK-6603 >> >> [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 >> to 4.4 >> >> manasaveloori Rajesh Battala 22/May/14 >> Actions >> CLOUDSTACK-6662 >> >> New XenServer host is not activated due to no agent connection >> >> Daan Hoogland Anthony Xu 22/May/14 >> Actions >> CLOUDSTACK-6730 >> >> [Automation] test_egress_fw_rules test case failing while applying FW rule >> >> Rayees Namathponnan Rayees Namathponnan 22/May/14 Actions >> CLOUDSTACK-6710 >> >> [Automation] VM snapshot failing with NPE in vmware >> >> Rayees Namathponnan Likitha Shetty 21/May/14 Actions >> CLOUDSTACK-6602 >> >> [UI] createNetworkACL API action param value passed incorrectly >> >> Jayapal Reddy Jessica Wang 20/May/14 >> Actions >> CLOUDSTACK-6675 >> >> NPE while executing updatePortForwardingRule >> >> Chandan Purushothama Alena Prokharchyk 20/May/14 Actions >> CLOUDSTACK-6673 >> >> cloudstack-setup-management make a chmod 777 on /root >> >> Milamber Unassigned 19/May/14 >> Actions >> CLOUDSTACK-6644 >> >> Unable to attach Volume to a VM as a System User >> >> Chandan Purushothama edison su 19/May/14 Actions >> CLOUDSTACK-6599 >> >> Template/Volume URLs expiration functionality not working >> >> Nitin Mehta Nitin Mehta 19/May/14 >> Actions >> CLOUDSTACK-6674 >> >> [Automation] [DB lock] When KVM agent is alert state, agent never trying to >> connect back >> >> Rayees Namathponnan edison su 14/May/14 >> Actions >> CLOUDSTACK-6572 >> >> [Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic >> >> Sowmya Krishnan Rajesh Battala 12/May/14 >> >> >> >> >> >> On Mon, May 26, 2014 at 2:05 PM, sebgoa <run...@gmail.com> wrote: >> > >> > On May 26, 2014, at 1:59 PM, Daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >> > >> >> I didn't get any reactions on this second proposal and though I know >> >> I can force discussion on it by just starting to implement it as well >> >> I would really get some consent on this. >> > >> > Can you send the list of those blockers to the list with the name of the >> reporter ? >> > >> >> >> >> On Fri, May 23, 2014 at 10:06 AM, Daan Hoogland >> >> <dhoogl...@schubergphilis.com> wrote: >> >>> I will start implementing this on Monday. >> >>> >> >>> Also I would like to propose that nothing is a blocker unless it has been >> agreed on, on list. >> >>> >> >>> -----Original Message----- >> >>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >> >>> Sent: donderdag 22 mei 2014 10:08 >> >>> To: dev >> >>> Subject: [ACS44][PROPOSAL] old blocker bugs >> >>> >> >>> LS, >> >>> >> >>> There are several blocker bugs registered for 4.4 that have not been >> touched for over a week. I seems strange to me that a blocker would be left >> alone for so long and I therefor propose to reduce priority of blockers that >> have not been touched for over a week to trivial. I have mailed reporters to >> a few querying about the status but this tactic doesn't work. >> >>> >> >>> thoughts? >> >>> >> >>> -- >> >>> Daan >> >> >> >> >> >> >> >> -- >> >> Daan >> > >> >> >> >> -- >> Daan -- Daan
