cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <Nitin.Me...@citrix.com>
Subject Re: [DISCUSS] [jira] make affectedVersion field mandatory.....
Date Mon, 05 Aug 2013 09:03:57 GMT
+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.Ganesh@citrix.com> wrote:

>> -----Original Message-----
>> From: Prasanna Santhanam [mailto:tsp@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
>


Mime
View raw message