[Meego-qa] BoF MeeGo Bugzilla Structure Enhancement Prototype in SF conference - Meeting minutes

[Wan, Shuang]

Resend it as it blocked by maillist due to too many recipients.

-----Original Message-----
From: Wan, Shuang 
Sent: Thursday, June 02, 2011 9:05 PM
To: 'Stephen Jayna'
Cc: eric.le-roux at nokia.com; Clark, Joel; shane.bryan at linux.intel.com; Wan, Shuang; meego-qa at lists.meego.com; Liu, Bing Wei; Van De Ven, Arjan; Nashif, Anas; Zhao, Fan
Subject: RE: [Meego-qa] BoF MeeGo Bugzilla Structure Enhancement Prototype in SF conference - Meeting minutes

Hi Steve,

I believe this is another topic we are trying to solve, a common bug applies for multiple branches, profiles or platforms but fix integration can't be happened at same time. 
My point is if a fix has been integrated for A but hasn't been ready or need extra efforts to fix it for B, then there should be a new bug entry for B even though the behavior and root cause are same. Otherwise how users say a bug has been fixed or not if fix only applies for A but not for B especially A and B are owned by different peoples and have different target on time to fix? And how users to get an overall view just from bugzilla search?
I believe this is the underlying concept that Eric bring up the deep clone patch into our MeeGo bugzilla.
@Eric, please correct me I am misunderstand it :-)

But from practice view, have a separated bug entry for each platforms (or branches, profiles) may introduce extra workload in bug follow up and hard to get a overall view on bug fix status in each branch just from one bug report. This is one area we want to improve, please see bellow bugzilla feature request for detail:
https://bugs.meego.com/show_bug.cgi?id=3187

For SUBMITTED status, my point is smaller granularity status helps to make thing clear and key to avoid ambiguity especially for deep integration with build infrastructure.

Thanks
Shuang

-----Original Message-----
From: Stephen Jayna [mailto:ext-stephen.jayna at nokia.com] 
Sent: Thursday, June 02, 2011 8:06 PM
To: Zhao, Fan
Cc: eric.le-roux at nokia.com; Clark, Joel; shane.bryan at linux.intel.com; Wan, Shuang; meego-qa at lists.meego.com; Liu, Bing Wei; Van De Ven, Arjan; Nashif, Anas
Subject: Re: [Meego-qa] BoF MeeGo Bugzilla Structure Enhancement Prototype in SF conference - Meeting minutes

Hello,

On 06/02/2011 10:09 AM, ext Zhao, Fan wrote:
>> Thursday, June 02, 2011 4:28 PM
>> ext-stephen.jayna at nokia.com wrote:
>>
>> This doesn't make sense:
>>
>> RESOLVED->FIXED
>> RESOLVED->SUBMITTED
>> RELEASED->SUBMITTED
>> VERIFIED->SUBMITTED
>>
>> The way the bug was resolved didn't change because it made it to trunk.
>>
>> Perhaps something like this is more palatable:
>>
>> RESOLVED->FIXED
>> SUBMITTED->FIXED
>> RELEASED->FIXED
>> VERIFIED->FIXED
>>
>> We can even go as far as having a status 'COMPILING' when we're
>> integrated with the build system and it wouldn't break the abstraction.
>> The bug would still have been resolved by being fixed.
>>
>> Anyway to conclude. We don't need a new resolution, the way bugs are
>> resolved isn't going to change. But instead lets add more precise
>> statuses. After all Elva said it earlier: "it will be very helpful to
>> track the bug status". Precisely: we're tracking the status.
>
> Your point makes sense to me. I agree it's logically clearer to make SUBMITTED as a status.

Excellent. I'll assume we all agree we no longer need a new resolution.

So let's take this a step further. What if I said we didn't need any new 
statuses either? In fact what if I were to suggest we could actually do 
away with both the proposed SUBMITTED *and* the RELEASED status?

Let's take RELEASED first.

(UNRESOLVED)
RESOLVED->FIXED
VERIFIED->FIXED

Shocking as it sounds - and as Shane pointed out earlier - the status of 
'RELEASED' doesn't really work. Released where? What if it's been 
released into X but not yet in Y. It could be both released and 
unreleased at the same time depending on the context. I don't like it, 
it's crude and worse still might not reflect reality.

We need to know the release status of the bug resolution for each 
context. Which leads me to think that 'RELEASED' isn't a status at all. 
I actually believe it's a distinct attribute of a bug.

The attribute would be prominently displayed as a list of builds (or 
whatever) where the fix is available for verification and would be set 
by a distribution engineer or automatically by the build system as the 
fix becomes available. I can't see what value the 'RELEASED' status 
would add if we had this.

Same deal with SUBMITTED. If you follow my logic on RELEASED you'll see 
why SUBMITTED doesn't work either. A fix may be submitted in multiple 
places (eg. trunk and an update branch). It's not simply a bug state.

Build automation will fully document where a fix has been submitted to 
and in turn where it has been released by adding comments to a bug. We 
should augment this by adding dedicated fields to allow users to search 
and report on where fixes have been made and whether they have been 
released.

I know it's tempting to shoe-horn attributes like where a fix has been 
submitted or released into the status drop-downs but it's an 
oversimplification and doesn't reflect what's really going on.

Regards,
Steve

>
>>
>> Oh and the 'COMPILING' bit was a joke but wouldn't it be ace?
>>
>> Regards,
>> Steve

-- 
Stephen Jayna

Email: ext-stephen.jayna at nokia.com
Jabber: jayna at ok.research.nokia.com | sdjayna at projects.maemo.org
Skype: stephenjayna
Tel (FI): +358 4657 728 29
Tel (UK): +44  7968 810 497