Bugzilla Configuration and Bug Tracking: Difference between revisions
| Line 362: | Line 362: | ||
=== Bug Life Cycle === | === Bug Life Cycle === | ||
A normal Bug's life is | A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. | ||
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]] | [[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]] | ||
Bug should be marked as | Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps. | ||
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[ | # Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[YOCTO #4321]''' | ||
# Developer asked tree gatekeeper to pull patch. | # Developer asked tree gatekeeper to pull patch. | ||
# Release Engineer do formal build. The build script will read new commit description and find out bug ID. | # Release Engineer do formal build. The build script will read new commit description and find out bug ID. | ||
# Build script will notify bugzilla and update bugs status to | # Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED''' | ||
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be | If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened. | ||
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]] | [[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]] | ||
Revision as of 23:25, 12 June 2017
Yocto Project Bug Process version
| Version | Modifier | Comments |
| 0.3 | Yongkang You | Initial Version |
| 0.5 | Yongkang You | Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it. |
| 0.8 | Yongkang You | Internal review and agree bug life cycle and bug Triage process. |
| 0.85 | Saul Wold | Add Bug Status / Sub-Status Definitions. |
| 0.9 | davest | Cleanup for 0.9 release. |
You should also read our Community Guidelines before submitting bugs.
Defect Management
Yocto uses Bugzilla as its defect tracking tool.
Home Address
http://bugzilla.yoctoproject.org
Get an Account
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.
To set up an account, go to the Yocto Bugzilla home page and click on "New Account" in the footer area. Follow the directions there to set up your account.
Classification, Product and Components
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:
+============================+===================================+=====================================================+ | Classification | Product | Components | |================================================================+=====================================================| | Build system, metadata & | BitBake | bitbake | | Runtime | | | | +-----------------------------------+-----------------------------------------------------| | | BSPs | bsps-configuration | | | +-----------------------------------------------------| | | | bsps-intel-corei7-64 | | | +-----------------------------------------------------| | | | bsps-meta-fsl-arm | | | +-----------------------------------------------------| | | | bsps-meta-fsl-ppc | | | +-----------------------------------------------------| | | | bsps-meta-intel | | | +-----------------------------------------------------| | | | bsps-meta-minnow | | | +-----------------------------------------------------| | | | bsps-meta-ti | | | +-----------------------------------------------------| | | | bsps-meta-xilinx | | | +-----------------------------------------------------| | | | bsps-meta-yocto | | | +-----------------------------------------------------| | | | bsps-oe-core | | | +-----------------------------------------------------| | | | bsps-runtime | | | +-----------------------------------------------------| | | | bsps-tools | | +-----------------------------------+-----------------------------------------------------| | | Meta-yocto | configuration | | | +-----------------------------------------------------| | | | meta-yocto | | +-----------------------------------+-----------------------------------------------------| | | OE-Core | configuration | | | +-----------------------------------------------------| | | | connectivity | | | +-----------------------------------------------------| | | | core | | | +-----------------------------------------------------| | | | deployment | | | +-----------------------------------------------------| | | | devtools /tool chain | | | +-----------------------------------------------------| | | | graphics | | | +-----------------------------------------------------| | | | kernel | | | +-----------------------------------------------------| | | | multimedia | | | +-----------------------------------------------------| | | | Scripts and Tools | | | +-----------------------------------------------------| | | | virtual machines | | +-----------------------------------+-----------------------------------------------------| | | Other YP Layers | baryon | | | +-----------------------------------------------------| | | | layers | | | +-----------------------------------------------------| | | | meta-cgl | | | +-----------------------------------------------------| | | | meta-intel-iot-middleware | | | +-----------------------------------------------------| | | | meta-security | | | +-----------------------------------------------------| | | | meta-swupd | | | +-----------------------------------------------------| | | | meta-zephyr | | +-----------------------------------+-----------------------------------------------------| | | Runtime | build-appliance | | +-----------------------------------+-----------------------------------------------------| | | Security - Recipe Upgrade | security | | +-----------------------------------+-----------------------------------------------------| | | Toaster | toaster | +----------------------------+-----------------------------------+-----------------------------------------------------| | Yocto Project Subprojects | ADT | adt | | | +-----------------------------------------------------| | | | kernel analysis | | +-----------------------------------+-----------------------------------------------------| | | Automated Update Handler | Automatic Update Handler | | +-----------------------------------+-----------------------------------------------------| | | CROPS | crops-default | | | +-----------------------------------------------------| | | | eclipse-crops | | +-----------------------------------+-----------------------------------------------------| | | Cross-prelink | cross-prelink | | | +-----------------------------------------------------| | | | poky integration | | +-----------------------------------+-----------------------------------------------------| | | Eclipse Plugin | eclipse-plugin | | +-----------------------------------+-----------------------------------------------------| | | Error Reporting Tool | Error Reporting Tool | | +-----------------------------------+-----------------------------------------------------| | | eSDK | eSDK | | +-----------------------------------+-----------------------------------------------------| | | IoT Reference OS Kit | intel-iot-refkit-application-support | | | +-----------------------------------------------------| | | | intel-iot-refkit-connectivity | | | +-----------------------------------------------------| | | | intel-iot-refkit-default | | | +-----------------------------------------------------| | | | intel-iot-refkit-documentation | | | +-----------------------------------------------------| | | | intel-iot-refkit-multimedia | | | +-----------------------------------------------------| | | | intel-iot-refkit-platform-support | | | +-----------------------------------------------------| | | | intel-iot-refkit-profile-computer-vision | | | +-----------------------------------------------------| | | | intel-iot-refkit-profile-gateway | | | +-----------------------------------------------------| | | | intel-iot-refkit-profile-industrial-robotics | | | +-----------------------------------------------------| | | | intel-iot-refkit-security | | | +-----------------------------------------------------| | | | intel-iot-refkit-software-update | | | +-----------------------------------------------------| | | | intel-iot-refkit-tools | | +-----------------------------------+-----------------------------------------------------| | | Kernel | kernel-configuration | | | +-----------------------------------------------------| | | | kernel-tooling | | | +-----------------------------------------------------| | | | linux-yocto | | +-----------------------------------+-----------------------------------------------------| | | Layer Index | Layer Index | | | +-----------------------------------------------------| | | | Layer Index Metadata | | +-----------------------------------+-----------------------------------------------------| | | Matchbox | matchbox | | +-----------------------------------+-----------------------------------------------------| | | opkg | opkg | | +-----------------------------------+-----------------------------------------------------| | | Patchwork/Patchtest | Patchtest | | | +-----------------------------------------------------| | | | Patchtest Testsuite | | | +-----------------------------------------------------| | | | Patchwork | | +-----------------------------------+-----------------------------------------------------| | | Pseudo | poky integration | | | +-----------------------------------------------------| | | | pseudo | | +-----------------------------------+-----------------------------------------------------| | | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) | | +-----------------------------------+-----------------------------------------------------| | | Sato | gtk-engine | | | +-----------------------------------------------------| | | | Icon | | | +-----------------------------------------------------| | | | Matchbox | | | +-----------------------------------------------------| | | | sato | +----------------------------+-----------------------------------+-----------------------------------------------------| | Documentation | ADT Manual | SDK | | +-----------------------------------+-----------------------------------------------------| | | BitBake User Manual | bitbake-manual | | +-----------------------------------+-----------------------------------------------------| | | BSP Guide | bsp-docs | | +-----------------------------------+-----------------------------------------------------| | | Demos | demos-docs | | +-----------------------------------+-----------------------------------------------------| | | Development Manual | devolopment | | +-----------------------------------+-----------------------------------------------------| | | General Docs | docs-general | | +-----------------------------------+-----------------------------------------------------| | | Kernel Development | kernel-development | | +-----------------------------------+-----------------------------------------------------| | | Mega Manual | mega-manual | | +-----------------------------------+-----------------------------------------------------| | | Profile and Tracing Manual | profile-manual | | +-----------------------------------+-----------------------------------------------------| | | Quick Start | quick-start | | +-----------------------------------+-----------------------------------------------------| | | Reference | handbook | | | +-----------------------------------------------------| | | | PRD | +----------------------------+-----------------------------------+-----------------------------------------------------| | Infrastructure | AutoBuilder | autobuilder | | | +-----------------------------------------------------| | | | jenkins autobuilder plugin | | +-----------------------------------+-----------------------------------------------------| | | Bugzilla | bugzilla | | +-----------------------------------+-----------------------------------------------------| | | Program Management | management-default | | +-----------------------------------+-----------------------------------------------------| | | Release Process | Release Process | | +-----------------------------------+-----------------------------------------------------| | | Testopia | testopia | | +-----------------------------------+-----------------------------------------------------| | | Website | web-admin | | | +-----------------------------------------------------| | | | web-content | | | +-----------------------------------------------------| | | | web-design | | | +-----------------------------------------------------| | | | web-structure | | +-----------------------------------+-----------------------------------------------------| | | Wiki | wiki | +----------------------------+-----------------------------------+-----------------------------------------------------| | QA/Testing | Automated Build Testing | automated-build-testing | | +-----------------------------------+-----------------------------------------------------| | | Automated Runtime Testing | automated-runtime-testing | | +-----------------------------------+-----------------------------------------------------| | | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing | | | +-----------------------------------------------------| | | | intel-iot-refkit-automated-runtime-testing | | | +-----------------------------------------------------| | | | intel-iot-refkit-manual-testing | | +-----------------------------------+-----------------------------------------------------| | | Manual Testing | manual-testing | | +-----------------------------------+-----------------------------------------------------| | | Test Plans/Suite | test-plans/suite | +----------------------------+-----------------------------------+-----------------------------------------------------| | Runtime | General Runtime | General Runtime | | +-----------------------------------+-----------------------------------------------------| | | Installation | Installation | | +-----------------------------------+-----------------------------------------------------| | | Package Management Issues | Debian Packaging - DEB | | | +-----------------------------------------------------| | | | ipkg opkg | | | +-----------------------------------------------------| | | | package-management-issues | | | +-----------------------------------------------------| | | | RPM | | +-----------------------------------+-----------------------------------------------------| | | Security | security | | +-----------------------------------+-----------------------------------------------------| | | System Startup | system-startup | +============================|===================================+=====================================================+
Platform
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:
- All
- PC
- Beagleboard
- BeagleBone
- Blacksand
- Cheifriver
- Crownbay
- E-Menlow
- EdgeRouter
- FRI2
- Galileo
- JasperForest
- MinnowBoard
- MinnowBoard Max
- mpc8315e-rdb
- Netbook
- NUC
- RouterStationpro
- TunnelCreek
- Macintosh
- Other
Here is a list of the Architecture choices:
- Multiple
- arm
- arm64
- mips
- mips64
- ppc
- ppc64
- x86
- x86_64
- Other
Version
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.
Here is a sample list of selections at given the last time this wiki page was updated:
- 2.0.3
- 2.0.4
- 2.1.2
- 2.1.3
- 2.1.4
- 2.2
- 2.2.1
- 2.2.2
- 2.2.3
- 2.3
- 2.3.1
- 2.3.2
- 2.4
- 2.5
- Unspecified
Target Milestone
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.
Importance
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:
- High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release.
- Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience.
- Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.
- Low -- Bug fixing is not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.
- Undecided -- These issues are newly reported and are undecided before Triage.
- FEAT -- Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Change Control Board (CCB) approves it.
Note: High impact but Low Priority bugs can be documented in the release notes.
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.
- Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
- Major -- Major loss of functionality of POR.
- Normal -- Regular issue, some loss of functionality under certain circumstance. This is the default Severity.
- Minor -- Minor loss of functionality, or issues with easy workaround available.
- Enhancement -- Request for enhancement work.
Bug Status
- NEW -- A new reported bug with default assignee.
- ACCEPTED-- The assigned developer has reviewed and accept the bug.
- RESOLVED -- bug is fixed or closed by other resolved method.
- FIXED -- This is fixed and in the master branch will be set automatically during build
- NOTABUG -- This is verified as not a bug
- WONTFIX -- We will not fix this bug, possibly because a newer package fixes it
- DUPLICATE -- Duplicate of another bug, possibly different failure mode
- INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to NEEDINFO
- OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
- WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be NEEDINFO
- VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.
- REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage.
- NEEDINFO: bug needs further information from someone in order to make progress on the bug.
- WAITFORUPSTREAM: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to WAITFORUPSTREA and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to RESOLVED/FIXED.
- CLOSED stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.
Bug Life Cycle
A normal Bug's life is starts from NEW and ends with VERIFIED. Triage team will select "verified: Program Management", after confirm the verification.
Bug should be marked as RESOLVED/FIXED, after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to RESOVLED/FIXED status by following steps.
- Developer fixed bug and check in patch to his contrib branch with special words in commit description: [YOCTO #4321]
- Developer asked tree gatekeeper to pull patch.
- Release Engineer do formal build. The build script will read new commit description and find out bug ID.
- Build script will notify bugzilla and update bugs status to RESOLVE/FIXED
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.
Defect Submission
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.
Bug Group
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.
- Security -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
- No_Group_Check_Box_Selection-- Bugs are public. (Be careful)
- TBD
Bug Reporter
- Provide clear and simple bug subject. It is recommended to put a Fault Component Name with brackets at the beginning of subject as a keyword, e.g. [Poky].
- Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
- Judge the right Severity.
- Adds any additional information from the bug scrub.
- Assigns the bug to the correct person to disposition the bug.
- If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
- Bug Priority can't be set when report a bug. It will be set when doing bug Triage
Bug Owner
- Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
- Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
- Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. Bug should not be marked as "fix", if patch is not checked into repository.
Bug Tracking
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named Triage to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.
Triage Management Team
- Program Manager
- Architect
- Engineering Manager
- QA leader
Triage Process
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.
The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.
Bug Triage Process
Triage email example
To: Yocto OTC Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1 Manager: MGR_A ================== Bug ID Sev Priority Assignee Summary 1 maj High dev_A [Poky] XYZ Build Failure Manager: MGR_B ==================== Bug ID Sev Priority Assignee Summary 2 maj High dev_B [SDK] ABC button error 3 nor Medium dev_C [X] Can't start X
Responsibility
- Triage Chairman
- Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
- Monitor overall bug fix progress with indicators: find out aging bugs.
- Send out triage result email to yocto mailing list (or Triage management team member) for review.
- Escalate aging high priority open bugs.
- Triage Management Team
- Development/Distribution managers are mandatory to review triage result and commit to fix
- Development/Distribution Manager
- Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
- Commit developer to fix high priority bugs
- Program Manager
- Coordinate and push bugs to be fixed in time
- Triage Decision Forum (PDT Meeting)
- Make decision on controversial bugs
- Review and Monitor previous decision
- Triage Chairman update bugzilla based on decision
- Discuss and approve bug whose priority needs to be downgraded
Triage Chairman
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
- Saul Wold -- Distro leader
- Susie Li -- engineer manager
- Kevin Tian -- distro leader
- Jessica Zhang -- SDK leader
- QA Leader
Bug Data Reporting
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.
External Owned Bug Triage
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.
Re-Triage for Next Milestone and Release
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone. After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.
Feature Request Process
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to FEAT.
There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.
Change Control Board
Following people should join CCB to review new feature request. PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader
Feature Request Bug Requirement
Feature request bug should be added specific Keywords in subject and Keywords field.
Following message should be added at the beginning of subject. [FEAT_REQ Company Yocto_Target_Version]
For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.
Following words should be added in Keywords field. FEATURE_REQUEST
Feature Request Bug Template
1. Feature Description: 2. Feature Present Code Status(including location and version): 3. Code License (e.g. GPLv2): 4. Business Impaction: 5. Other Justification:
Bug Tracking template
- Headline (tittle).
- Steps to reproduce it, (Expected and actual results).
- Reproducibility.
- Attachments (pics, logs).
- Build Description ( poky commit, machine, HW, test environment).
- AB Link.
- Summary (on Description).
- Additional Versions or HW.
- Link to corresponding test case.
Best Practices redacting headline
1. No more than 12 words.
2. In 12 words include:
a) Who. b) What. c) When.
Examples:
1. SATO-sdk displays panics kernel when trying to Install from USB.
SATO-sdk = Who.
Displays panics kernel = What.
Trying to Install from USB = When.
2. Git revision field editing fail on importing layers.
Git revision field = Who.
Editing fail = What.
On imporing layers = When.
Note: You can describe "How" to reproduce it in the description.
