DarioAndres (Talk | contribs) (→Fields of a bug report) |
(→Modifying a bug report (permissions required)) |
||
| Line 182: | Line 182: | ||
Finally you can modify the bug report status: | Finally you can modify the bug report status: | ||
| − | * Mark | + | * Mark it as confirmed (NEW) |
* Mark it as fixed or non-reproducible (RESOLVED as FIXED or RESOLVED as WORKSFORME) | * Mark it as fixed or non-reproducible (RESOLVED as FIXED or RESOLVED as WORKSFORME) | ||
* Mark it as duplicate of another bug report (DUPLICATE of bug report XXXXXX) | * Mark it as duplicate of another bug report (DUPLICATE of bug report XXXXXX) | ||
Bugzilla is the bug tracking software the KDE community uses to handle the bug reports of their applications.
Our bugtracker is located at https://bugs.kde.org
Main screen of the bugtracker (default style):
Contents |
Summary: Brief description of the bug
Product: Application or library which is being affected by the bug
Component: Specific component inside the product which is being affected by the bug
Version: Version of the application or library which shows the bug (Note: different products could have different policies about this field: it could represent the last version in which the bug is present, or the first version in which the bug appeared). This field defaults to "unspecified".
Priority: Priority of the bug report. It defaults to "NOR"(normal) and it must not be changed.
Severity: Type of bug:
Status: Status of the bug report:
Votes: Current number of votes the bug report has. Votes can be useful to confirm a bug (status changes from UNCONFIRMED to NEW).
Comments: The first comment is always the original description of the bug sent by the reporter. The other ones could be comments added by the same reporter or by any other user, a bug triager, or a developer.
Keywords: Special words which are used to mark special reports, in order to find them easily. Several keywords can be used separated by commas.
CC List: List of mail addresses (from reporters or contributors) who are tracking the bug report and who are going to get a mail notification about every change on it.
More information about bug report's life cycle and other fields can be found at https://bugs.kde.org/page.cgi?id=fields.html
Prior to start using your bugzilla account, it is important to configure it.
You can access your control panel using the "Edit my Preferences" link or with this URL: User Preferences
With the default behavior, after you modify a bug report (or after adding a comment) you will be redirected to another bug report (the next in your search list). Most of the users get confused with this behavior and write other comment in that bug report, thinking it is the same as before.
You can properly identify each KDE application with its bugzilla product component using this feature: Describe components
The simple search provides a quick way to look for bug reports without the need to specify too much specific fields filters.
In the Status field you can select:
In the Product field you select the main application or library suffering the bug
In the Words field you can enter some keywords which will be used to identify the bug report (it will search trying to match those words with the Summary of the report) You can use keywords or a complete phrase You can also leave this field empty to look for all the bug reports
Search for currently active Plasma bug reports about icons being misplaced on login.
* Status: "Open" * Product: "Plasma" * Words: "icon move login" or "icons are randomly moved during the startup"
This kind of search allows the user to filter a lot of fields using several combinations.
The important field in this form are:
You can setup a date delimiter using the "Bug Changes" group: you can set two dates and select a field to compare: "Bug creation", "Last modification", and so on. The dates' format can be "YYYY-MM-DD", "Xd" (X days), "Xm" (X months), "Now" (Today)
You can filter reports which are assigned or have comments of a specific user using the "Email address, bug number and votes" group.
You can also select the sort method to use: by bug number, by importance, by last order used.
Fields which could remain untouched (as they are not really useful to filter out. And we don't use some of them): "Target", "The URL", "Keywords", "Priority", "Hardware", "OS"
Search for bugs in the folderview widget (Plasma-desktop) related to the preview of images not working on a network share, currently opened and confirmed:
* Summary: "preview fail" or "preview not working" * Product: "plasma" * Component: "widget-folderview" * A Comment: "network" or "network share" or "remote" * Status: "NEW", "ASSIGNED" and "REOPENED" * Severity: "minor" and "normal" (it is not a crash and it is not a major bug)
With the default style you can easily recognize the different type of bug reports by colors (red are crashes, yellow are normal reports and green are feature requests)
In every bug report page, you will find a textbox (below the comments) which allows you to add a comment to that report
In this textbox you can describe your discovery: you can(not) reproduce the bug; you can provide more information or details. You can also request more information from the reporter
When you are ready, click the Commit button
If you have the enough bugzilla permissions, you can modify more fields of a bug reports. This is oftenly useful while organizing ("triaging") the reports.
You can:
Then you can:
Finally you can modify the bug report status: