Bugzilla Configuration and Bug Tracking: Difference between revisions
(39 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
You should also read our [[Community Guidelines]] before submitting bugs. | You should also read our [[Community Guidelines]] before submitting bugs. | ||
Line 263: | Line 247: | ||
</pre> | </pre> | ||
=== | === 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 | 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 | * All | ||
Line 302: | Line 286: | ||
=== Version === | === 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. Here is a list of | 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: | |||
* 0. | * 2.0.3 | ||
* | * 2.0.4 | ||
* 1. | * 2.1.2 | ||
* 1.1 | * 2.1.3 | ||
* 1.1 | * 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 === | === Target Milestone === | ||
This field represents | 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 === | === 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: | 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. | * 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. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team. | ||
* 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+ -- 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. | * 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. | * Low -- Bug fixing is only done opportunistically. Generally 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. | * Undecided -- These issues are newly reported and are '''undecided''' before Triage. 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 Triage team approves it. | ||
'''Note:''' High impact but Low Priority bugs can be documented in the release notes. | '''Note:''' High impact but Low Priority bugs can be documented in the release notes. | ||
Line 331: | Line 325: | ||
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity. | * 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. | * Minor -- Minor loss of functionality, or issues with easy workaround available. | ||
* Enhancement -- Request for enhancement | * Enhancement -- Request for enhancement or new feature to be worked. | ||
=== Bug Status === | === Bug Status === | ||
* | * NEW -- A new reported bug with default assignee. | ||
* ACCEPTED-- The assigned developer has reviewed and accept the bug. | * 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''' or it is not a feature of Yocto Project to fix. | ||
** | ** 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. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from. | ||
* '''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 === | === 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 (e.g. '''[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]] | ||
== | == Submitting and Owning a Defect == | ||
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. | |||
=== Bug | === Bug Submitter === | ||
When you submit (open) a bug, be sure to do the following: | |||
# Provide a 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 and select the appropriate Severity. | |||
# Add any additional information from the bug scrub. | |||
# Assign 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 '''NEEDINFO''' and sent back the bug submitter. | |||
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect. | |||
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution. | |||
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage. | |||
=== Bug Owner === | === Bug Owner === | ||
If you are the owner of a bug, be sure to do the following: | |||
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. | |||
# Try to reproduce your bugs when clear steps exist in the bug's description. | |||
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system. | |||
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository. | |||
== Bug Tracking == | == Bug Tracking == | ||
Yocto is a | Because the Yocto Project spans many geographies and is a large and active project, a single bug scrub meeting is not easy to maintain. Consequently, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity and features and then schedules the bug to best facilitate a resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]. | ||
Part of the Triage process is the distribution of a weekly Bugzilla Cleanup Request. This email request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request. For the actual request, links to lists of bugs exist that allow you to see the list of bugs that fail to meet a particular requirement: | |||
''' | *'''No Estimate:''' You own a medium or higher priority bug or enhancement in Bugzilla targeted for completion in the given release. Do to the amount of work trying to get done in Yocto Project, we are asking you take a minute or two and give an estimated amount of work – in "Perfect-Work-Days" – to complete the bug or enhancement. We know your estimates might not be perfect. However, this effort helps us know who is overloaded with work and where to apply the resources we have on the project. Please estimate how many "Perfect-Work-Days" remain to close the bugs in the "Estimate: Person-Days" box in Bugzilla. Also while updating the bug or enhancement, please ensure the estimate targets the correct Milestone for completion. | ||
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker whose assigned milestone is old. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has already passed, please do one of the following actions: | |||
**If it is completed: Close the bug. (Great News!) | |||
**If it is partly complete: Break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone. | |||
**If it is not done at all but you still plan to fix it in the future: Move the bug to milestone that is not yet completed. (Future is a possible milestone.) | |||
**If it is no longer in your plans to do this but you think this still needs to be fixed: Change the bug to an unassigned priority. During the Triage process, we will assess the bug again and appropriately reassign the bug. | |||
**If it no longer makes sense to fix this bug: Please close the bug request with a status of either OBSOLETE or WONTFIX. | |||
''' | *'''Needs specific milestone:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker that has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). Medium+ and High bugs are not allowed to be set to the "Future" milestone but can be set to the milestone 2.99 which time to complete is still TBD. | ||
*'''Needs to be broken up:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker that is a medium or higher priority and has more than five "Perfect-Work-Days" assigned. All open medium or higher bugs with more than five days should be broken into smaller dependent tasks. If this is not possible please contact the Yocto Project program manager with bug number and an explanation of why it can't be broken into small tasks. | |||
*'''Dependency Issue:''' You have a dependency problem in Yocto Project Bugzilla tracker where either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with the bug. | |||
*'''Need Info > 2 Weeks:''' You have bugs or requested enhancements for the Yocto Project for which more information has been requested in order to allow progress on these bugs. These bugs or enhancements have been in this state waiting for this information from you for at least two weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you cannot supply the information, please change the bug's status to CLOSED and the resolution to either OBSOLETE or WONTFIX, whichever is more appropriate. | |||
* | |||
# | |||
== Feature Request Process == | == Feature Request Process == | ||
New feature request should be applied through Bugzilla as a bug. User | New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings. | ||
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October. | |||
Revision as of 20:51, 11 May 2018
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. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.
- 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 only done opportunistically. Generally 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. 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 Triage team 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 or new feature to be worked.
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 or it is not a feature of Yocto Project to fix.
- 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. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.
- 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 (e.g. [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.
Submitting and Owning a Defect
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.
Bug Submitter
When you submit (open) a bug, be sure to do the following:
- Provide a 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 and select the appropriate Severity.
- Add any additional information from the bug scrub.
- Assign 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 NEEDINFO and sent back the bug submitter.
- Make sure you edit the CC list to include other people you might think should know about the defect.
- Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.
NOTE: You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.
Bug Owner
If you are the owner of a bug, be sure to do the following:
- Review your bugs to check if there is enough information. If not, set the bug to NEEDINFO.
- Try to reproduce your bugs when clear steps exist in the bug's description.
- Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.
- Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to FIXED and provide the tree/commit information once the bug is fixed. You should not mark a bug as RESOLVED/FIXED, if the patch is not checked into the repository.
Bug Tracking
Because the Yocto Project spans many geographies and is a large and active project, a single bug scrub meeting is not easy to maintain. Consequently, a Triage is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity and features and then schedules the bug to best facilitate a resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at Bug_Triage.
Part of the Triage process is the distribution of a weekly Bugzilla Cleanup Request. This email request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request. For the actual request, links to lists of bugs exist that allow you to see the list of bugs that fail to meet a particular requirement:
- No Estimate: You own a medium or higher priority bug or enhancement in Bugzilla targeted for completion in the given release. Do to the amount of work trying to get done in Yocto Project, we are asking you take a minute or two and give an estimated amount of work – in "Perfect-Work-Days" – to complete the bug or enhancement. We know your estimates might not be perfect. However, this effort helps us know who is overloaded with work and where to apply the resources we have on the project. Please estimate how many "Perfect-Work-Days" remain to close the bugs in the "Estimate: Person-Days" box in Bugzilla. Also while updating the bug or enhancement, please ensure the estimate targets the correct Milestone for completion.
- Old Milestone: You are assigned an open bug in the Yocto Project Bugzilla tracker whose assigned milestone is old. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has already passed, please do one of the following actions:
- If it is completed: Close the bug. (Great News!)
- If it is partly complete: Break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.
- If it is not done at all but you still plan to fix it in the future: Move the bug to milestone that is not yet completed. (Future is a possible milestone.)
- If it is no longer in your plans to do this but you think this still needs to be fixed: Change the bug to an unassigned priority. During the Triage process, we will assess the bug again and appropriately reassign the bug.
- If it no longer makes sense to fix this bug: Please close the bug request with a status of either OBSOLETE or WONTFIX.
- Needs specific milestone: You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker that has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). Medium+ and High bugs are not allowed to be set to the "Future" milestone but can be set to the milestone 2.99 which time to complete is still TBD.
- Needs to be broken up: You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker that is a medium or higher priority and has more than five "Perfect-Work-Days" assigned. All open medium or higher bugs with more than five days should be broken into smaller dependent tasks. If this is not possible please contact the Yocto Project program manager with bug number and an explanation of why it can't be broken into small tasks.
- Dependency Issue: You have a dependency problem in Yocto Project Bugzilla tracker where either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with the bug.
- Need Info > 2 Weeks: You have bugs or requested enhancements for the Yocto Project for which more information has been requested in order to allow progress on these bugs. These bugs or enhancements have been in this state waiting for this information from you for at least two weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you cannot supply the information, please change the bug's status to CLOSED and the resolution to either OBSOLETE or WONTFIX, whichever is more appropriate.
Feature Request Process
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.