From Fedora Project Wiki

< SIGs‎ | KDE

(New page: Bugs determined to be packaging or configuration issues will be assigned to the package maintainer. For all others you need to search upstream bugs for a match. If none exists then set t...)
 
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
Bugs determined to be packaging or configuration issues will be assigned to the package maintainer.  For all others you need to search upstream bugs for a matchIf none exists then set the report to NEEDINFO from the Reporter and request they file upstream and add upstream info to the Fedora bug report. Otherwise add the upstream bug info to the local report.  Either way once done close the bug as UPSTREAM.
{{admon/important|Work In Progress|This is a work in progressComments to tuxbrewr /at/ fedoraproject.org.}}


All bugs which are currently ASSI will be pinged every 30 days.  Check to see if the package maintainer has requested more info from the reporter, if so make sure to change the report to NEEDINFO Reporter.  If there has been no movement at all you can request the reporter confirm it is still and issue and ask the maintainer for any updates.
This is based on the flowchart below and is the method used by the KDE triage team.


All bugs which are NEEDINFO will also be pinged every 30 days.  On the 1st ping just add a comment requesting the reporter/maintainer respond to the ping, make sure to include the comment that if there is no response within 30 days the bug will be closed as INSUFFICIENT_DATA.  On the 2nd ping (ie after 60 days) if there has been no response close the bug as INSUFFICIENT_DATA.
[[Image:Bugflow.png]]


Make sure you join #fedora-kde on Freenode and if you are unsure about a bug report just ask.
= 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.

Latest revision as of 11:43, 4 May 2010

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.

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.