[Meego-qa] BoF MeeGo Bugzilla Structure Enhancement Prototype in SF conference - Meeting minutes
shuang.wan at intel.com
Thu Jun 2 17:46:26 PDT 2011
Resend it as it blocked by maillist due to too many recipients.
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
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:
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.
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
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:
>> The way the bug was resolved didn't change because it made it to trunk.
>> Perhaps something like this is more palatable:
>> 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.
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
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.
>> Oh and the 'COMPILING' bit was a joke but wouldn't it be ace?
Email: ext-stephen.jayna at nokia.com
Jabber: jayna at ok.research.nokia.com | sdjayna at projects.maemo.org
Tel (FI): +358 4657 728 29
Tel (UK): +44 7968 810 497
More information about the MeeGo-qa