Hi Eric, > >> > >> I wrote yesterday a bug for multiple platforms: > >> Bug 19138 - HW platform field doesn't support multi-selection > >> https://bugs.meego.com/show_bug.cgi?id=19138 > >> > >> And added new one: > >> Bug 19183 - HW Verification field visible even the functionality not > >>ready yet > >> https://bugs.meego.com/show_bug.cgi?id=19183 > >> > > > >Thanks Iekku doing so. > > > >Since this involves bug management process on bug fix and verification. I > >would like Steve could share some basic ideas on this feature especially > >for following items: > > > >There are a couple of platforms that MeeGo needs to support, how we > >record the fix on each platforms in backend? > >This involves which technical choice is used for recording this > >information in DB backend, create a separated custom field for each > >platform or use multiple selection field as suggested by Iekku or any > >other solutions? > > > >In addition, the HW verification field can only hold verification > >information, how we handle the fix integration etc information in each > >platform. And how we say a bug is fixed is really fixed especially for > >bug could be reproduced on several platforms but target date to fix is > >different for each platform? > > > >If we support multiple HW verification, then we may need to change the > >platform field to multiple selectable. So users will be able to identify > >which platforms the bug could be reproduced. Here is the feature request > >for this: > >https://bugs.meego.com/show_bug.cgi?id=18473 > > As Steve mentioned this multiple HW verification feature was accidentally > deployed to production and sandbox. > It's now entirely removed so no confusion for anyone. > As earlier discussed, this implementation has caveats and the points you > raise above require another approach.
Thanks for your clarify. > As you know, bugzilla upstream brought in a similar feature called > "screening" see > https://landfill.bugzilla.org/bug55970/show_bug.cgi?id=11575 > The patch seems to better address the needs you express above. > > My recommendation is that you and Dayu put up a sandbox with bugzilla > version 4 latest stable (http://www.bugzilla.org/releases/4.0.1/), set it > up with bugs.meego.com database and theme and extensions and we can start > fresh from there rather than trying to tweak our implementation. > Also note that this gives you a chance to demonstrate how you can lose the > CLOSED status and is also a good base for your current work on bug > reporting from packages. > New features in 4.x branch like automatic duplicate detection, > autocomplete for user fields, and all the new hooks are just plain good. > > The stage is yours! > > Go ahead and we can discuss on how to move forward once you have > something > to show... Yeah, this the upstream patch we demoed at last year. Okay, we will works on this further and come back to discussion when we have more mutual proposal ready. > As agreed, you have to use gitorious to host the code and expose the > changes so we can review them efficiently. > Here is the repository: http://gitorious.org/meego-bugzilla/bmc > You're already familiar with what needs to be done since you kindly > documented it earlier on the ML ;) > This open approach will allow all of us to get a good grasp on what is the > best implementation for any of the needed changes or new features > mentioned above. In addition, I just drafted a wiki page at meego.com wiki based on the discussions at F2F and ML, see bellow: http://wiki.meego.com/Quality/BugzillaRequestProcess Welcome to revise it if something lost or incorrect ;) > > Cheers, > Eric > Thanks Shuang _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
