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

[eric.le-roux at nokia.com]

Hi,

On 5/31/11 12:43 PM, "ext Andre Klapper" <aklapper at openismus.com> wrote:

>On Tue, 2011-05-31 at 09:36 +0800, Wan, Shuang wrote:
>> We had a MeeGo QA BoF at San Francisco conference for demonstrating
>> bugzilla structure enhancement prototype:
>
>Was this announced somewhere, for those that could not attend the
>session, or is this email the announcement itself?
>
>Is the structure enhancement outlined and documented on a MeeGo wikipage
>(URL?), or can I just look at it by clicking around in
>https://02.bugs-dev.meego.com/ ?
>I don't expect something as shiny as
>http://www.gerv.net/temp/bmo-reorg.html but an outline would be welcome.

I doubt this one or the earlier attempt have been documented, we had only
sandboxes to refer to.

>
>
>> We had a brief explanation of basic motivation & idea and then demoed
>> the prototype Bugzilla to attendees.
>
>For those not being able to attend the session in San Francisco:
>Motivation is outlined in the slides that are available at the
>conference website.
>
>
>> Q2: There should be a group of peoples working on the package:
>> developer, legal guys etc;
>> 
>> A2: Currently Bugzilla only supports default assignee and QA contact.
>> For other relevant peoples could be presented on default cc list.
>
>Having virtual contacts might be another concept worth to consider:
>Creating fake users in Bugzilla like $product-owner at meego.bugs and
>making them Default QA or Default Assignee of product$).
>We use this in GNOME Bugzilla and it works well for us.
>
>Advantage: Anybody interested in following bug reports of a certain
>product can add this fake user to their watchlist in the Email
>Preferences; plus no need for Bugzilla maintainers to manually reassign
>or change default owners in case that module ownership changes (new
>owners can add the particular fake user to their Bugzilla watchlist
>themselves).
>Disadvantage: Less visibility of "real" QA contact or assignee in bug
>reports themselves.

As I already pointed, we have an extension that allows the concept of team
in bugzilla. This would allow, with some little effort to make it relevant
to MeeGo context (it's currently designed to support SCRUM activities), to
get rid of the problem we have without trying to replace QA by maintainer
as default assignees since this surely doesn't solve anything.
I'm rather confident we can nail down this issue with the BUS (Bugzilla
Ultimate Scrum) extension as long as we have a master database from which
we'd pull the basic package information, at least the maintainer's name
and keep in sync.
David Greaves suggested a package database as master authority and I quite
support his proposal.

>
>
>> Q3: The SUBMITTED resolution is not necessary. We could enforce
>> developer to set the bug status to RESOLVED FIXED only when the fix is
>> integrated into OBS.
>> 
>> A3: We may need to distinguish these 2 statuses RESOLVED FIXED and
>> RESOLVED SUBMITTED. The RESOLVED FIXED is used to mark the fix has
>> been submitted into git tree personal repository branch and later one
>> is used to mark the fix has been submitted into git tree main line
>> branch. 
>
>Hmm, this breaks the abstraction layer of Statuses (e.g. RESOLVED) and
>Resolutions (e.g. FIXED or WONTFIX), as a bug is expected to always
>receive the resolution SUBMITTED after having had the resolution FIXED
>anyway, while keeping the Status RESOLVED. This does not really make me
>happy but I cannot come up with a better idea either.
>
>For the records (this was mentioned in the BoF):
>A potential "SUBMITTED" resolution or status should be automatically set
>by integration with BOSS. For an example, see the comments added by
>"bossbot" to https://bugs.meego.com/show_bug.cgi?id=16881 .

+1

No need for extra status/resolution as long as the actual "fixing" is
documented and automated as shown in bug #16881.

To answer Luis' question earlier:
With the automated approach, iow, a bug is resolved FIXED only when it has
been accepted in OBS and properly documented (link to the repo and commit
message) you do not need to take any further action on the bug and can
focus on fixing the next one ;)
Eventually, only a limited set of users could bypass the automation and
manually set bugs to FIXED resolution.
Same applies for RELEASED status, fully automated and documented in the
bug comment and specific credentials for manual releasing to the release
engineers.
The only thing we ask developers to comply with is:
- proper documentation of changelogs (you need to specify a fix or feature
implementation like "Fixes BMC #1234 blah blah" in the changelog else your
submission is rejected with a warning). Alternatively, the same
information present in your commit message could also be accepted, though
we'd rather stick to changelog.

Hope this clarifies.

Cheers,
Eric
MeeGo EM Lead

>
>andre
>
>-- 
>Andre Klapper (maemo.org bugmaster)
>http://www.openismus.com
>
>_______________________________________________
>MeeGo-qa mailing list
>MeeGo-qa at lists.meego.com
>http://lists.meego.com/listinfo/meego-qa