What is the process to follow - Should a bug be raised against Apache JIRA to effect this change? Can someone let me know.
Thanks, RamG > -----Original Message----- > From: Nitin Mehta [mailto:nitin.me...@citrix.com] > Sent: 05 August 2013 14:35 > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] [jira] make affectedVersion field mandatory..... > > +1. > It would be good to have a default field probably as well ? > I would also want to have the fixVersion having default field and the release > manager accordingly triaging it. > I recently saw some of my bugs missed this information and the UI team > didn't notice it. > > On 05/08/13 12:57 PM, "Ram Ganesh" <ram.gan...@citrix.com> wrote: > > >> -----Original Message----- > >> From: Prasanna Santhanam [mailto:t...@apache.org] > >> Sent: 02 August 2013 23:36 > >> To: dev@cloudstack.apache.org > >> Subject: Re: [DISCUSS] [jira] make affectedVersion field mandatory..... > >> > >> On Fri, Aug 02, 2013 at 11:06:53AM +0000, Ram Ganesh wrote: > >> > Hi, > >> > > >> > While triaging bugs I noticed that many bugs had affectedVersion > >> > field as empty. This makes it difficult to guess the > >> > version/release the reporter was on while filing the bug. Can we > >> > make the affectedVersion field a mandatory field instead? > >> > >> Indeed this would be nice to have. But the reason I think we are not > >>seeing it is not knowing what the affectsVersion should be. > >> > >> Bugs are coming from: > >> > >> 1) Users reporting from the field > >> 2) QA filing bugs from jenkins builds > >> 3) Bugs encountered on master faced by those working on code > >> > >> Those in 1) usually add the information to their description. But > >>could use a command line method to extract this information to make > >>reports clearer. > >> Alex made an enhancement to add this to the jar's manifest. But it's > >>still not something that can be extracted easily. > >> > >> Those in 2) don't know if an unreleased -SNAPSHOT version of the > >>build would need to be put in the affectsVersion and if so what the > >>HEAD of the build is. Again a tool would help. Because one who fixes > >>the bug will almost > >> *always* need the commit-sha1, without which reproducing the bug can > >>be tough. > >> > >> and those in 3) don't have any option on JIRA so I've started to set > >>affectsVersion to 'Future' to denote master and add the HEAD of my > >>repo in the description. I notice these can get improperly triaged. > > > >Prasanna, > > > >For starters one need to populate just the release numbers like 4.1. or > >4.2 or 4.2+( if it is from master and release number is still agreed on). > > I am sure users would know the specific release number the problem was > >noticed. > > > > > >> > >> -- > >> Prasanna., > >> > >> ------------------------ > >> Powered by BigRock.com > >
