No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{admon/important|Work In Progress|This is a work in progress. Comments to tuxbrewr /at/ fedoraproject.org.}} | {{admon/important|Work In Progress|This is a work in progress. Comments to tuxbrewr /at/ fedoraproject.org.}} | ||
This is based on the flowchart below and is the method used by the KDE triage team. | |||
[[Image: | [[Image:Bugflow.png]] | ||
= How to triage KDE in Fedora = | = How to triage KDE in Fedora = | ||
| Line 10: | Line 11: | ||
2. You can then create a search in the RedHat Bugzilla for bugs filed against component you are interested in. You will need to specify the following to only include bugs which have not been triaged. Status must be NEW and the keyword Triaged should not have been set. | 2. You can then create a search in the RedHat Bugzilla for bugs filed against component you are interested in. You will need to specify the following to only include bugs which have not been triaged. Status must be NEW and the keyword Triaged should not have been set. | ||
3. Check for duplicates. Open 2 additional tabs in your browser of choice, with 1 tab containing bugzilla.redhat.com and the other bugs.kde.org. This will allow you to search for duplicates while keeping the original report available. If you find a duplicate in the redhat bugzilla you can close the new report as a duplicate of the existing report. If there is existing report in the redhat bugzilla then you can check the kde bug system to see if the issue has already been reported upstream. If it has then note the upstream bug # in the redhat report and close it as UPSTREAM. If | 3. Check for duplicates. Open 2 additional tabs in your browser of choice, with 1 tab containing bugzilla.redhat.com and the other bugs.kde.org. This will allow you to search for duplicates while keeping the original report available. If you find a duplicate in the redhat bugzilla you can close the new report as a duplicate of the existing report. If there is existing report in the redhat bugzilla then you can check the kde bug system to see if the issue has already been reported upstream. If it has then note the upstream bug # in the redhat report and close it as UPSTREAM. If no upstream report exists then continue to step 4. | ||
4. | 4. Is the issue being reported one that the KDE-SiG can handle? ie. a packaging issue, or is it something that exists in the upstream code and therefore effects more than just Fedora. If it can be handled locally proceed to #5, else request that the reporter file the issue upstream. Give them 30days to file the upstream report. Once they have files the upstream report, be sure to document the upstream bug# in our report and then close ours as UPSTREAM. If they fail to file the upstream report close the bug as INSUFFICIENT_DATA. | ||
5. Does the report contain all the required information information to isolate and correct the issue. If not document the report with what is needed and set the NEEDINFO flag. We will come back to the report later and check for updates, if after 30days the reporter has not supplied the requested info close the report as INSUFFICIENT_DATA, however be sure to note that once the info is provided they can reopen the report. | |||
6. At this point we should have a complete report that contains everything needed for the devs to work on a fix. At this point add the word TRIAGED to the bug report, and your work is done. | |||
Latest revision as of 11:43, 4 May 2010
This is a work in progress. Comments to tuxbrewr /at/ fedoraproject.org.
This is based on the flowchart below and is the method used by the KDE triage team.
How to triage KDE in Fedora
1. Identify the component(s) you wish to triage and request the WATCHBUGZILLA ACL in the Fedora Package Database. This will insure you are CC'd on any new bugs submitted against that component.
2. You can then create a search in the RedHat Bugzilla for bugs filed against component you are interested in. You will need to specify the following to only include bugs which have not been triaged. Status must be NEW and the keyword Triaged should not have been set.
3. Check for duplicates. Open 2 additional tabs in your browser of choice, with 1 tab containing bugzilla.redhat.com and the other bugs.kde.org. This will allow you to search for duplicates while keeping the original report available. If you find a duplicate in the redhat bugzilla you can close the new report as a duplicate of the existing report. If there is existing report in the redhat bugzilla then you can check the kde bug system to see if the issue has already been reported upstream. If it has then note the upstream bug # in the redhat report and close it as UPSTREAM. If no upstream report exists then continue to step 4.
4. Is the issue being reported one that the KDE-SiG can handle? ie. a packaging issue, or is it something that exists in the upstream code and therefore effects more than just Fedora. If it can be handled locally proceed to #5, else request that the reporter file the issue upstream. Give them 30days to file the upstream report. Once they have files the upstream report, be sure to document the upstream bug# in our report and then close ours as UPSTREAM. If they fail to file the upstream report close the bug as INSUFFICIENT_DATA.
5. Does the report contain all the required information information to isolate and correct the issue. If not document the report with what is needed and set the NEEDINFO flag. We will come back to the report later and check for updates, if after 30days the reporter has not supplied the requested info close the report as INSUFFICIENT_DATA, however be sure to note that once the info is provided they can reopen the report.
6. At this point we should have a complete report that contains everything needed for the devs to work on a fix. At this point add the word TRIAGED to the bug report, and your work is done.