CommonTasks

Differences between revisions 1 and 46 (spanning 45 versions)
Revision 1 as of 2005-11-02 20:13:35
Size: 1209
Editor: 209
Comment:
Revision 46 as of 2007-03-29 18:58:29
Size: 8030
Editor: c-24-21-235-175
Comment: Added release numbers to distro names
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Finding Duplicates of bugs is a very valuable contribution in the Bug community. Users sometimes don't know, how to check if the same bug was already filed, and sometimes don't care. To weed out simple '''ME TOO''' messages and aggregate information in one place is crucial in the process of fixing a bug. ## page was renamed from Bugs/CommonTasksDraft
== Overview ==
Line 3: Line 4:
There are quite some measures you can take to help out with this specifically. [[TableOfContents]]
Line 5: Line 6:
Look up bugs for the same component. Try to rephrase your search concentrate on ''actions'' an ''words that describe'' the items involved to reproduce this crash. == The proper source package ==

Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in {{{Ubuntu}}}. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to {{{Ubuntu}}}. Some hints on finding the right package can be found in ["Bugs/FindRightPackage"].

The correct package for bugs in the Linux kernel is dependent upon the release of Ubuntu being used.

 * For Breezy (5.10) the correct package is linux-source-2.6.12
 * For Dapper (6.06) the correct package is linux-source-2.6.15
 * For Edgy (6.10) the correct package is linux-source-2.6.17
 * For Feisty (7.04) the correct package is linux-source-2.6.20
 

== Confirming problems ==

If a bug is marked as {{{Unconfirmed}}}, it is helpful for you to try to reproduce the problem, and record the results in Malone. If you are able to confirm the problem, you may change the status to {{{Confirmed}}}. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment. Please do not confirm your own bugs - confirmation is required from someone other than the original reporter.


== Forwarding bugs upstream ==

You can forward bugs to the authors of the software (upstream), if
 * you made sure that the bug doesn't occur because of Ubuntu related changes,
 * the change is too hard to be fixed by yourself or anyone else in the team.

To learn how to do this, please consult [https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7 The Forwarding section in the How to Triage Page].

== How to Deal with Feature Requests ==

If you feel that the bug reported is a feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, ["SpecTemplate"] and http://launchpad.net/specs


== How to deal with Support Requests ==

If you feel that the bug reported is a support request disguised as a bug report, please introduce the reporter gently to the Support Tracker we have. Be sure to mention http://launchpad.net/support


== How to deal with suggestions for changing defaults ==

If you feel that the bug reported is a suggestions for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments.


== Finding Duplicates ==

Finding duplicates of bugs is a very valuable contribution in the Bug community. Users sometimes don't know how to check if the same bug has already been filed, and sometimes they don't care. Weeding out simple '''ME TOO''' messages and aggregating information in one place is crucial to the process of fixing a bug.

There are quite a few measures you can take to assist with this aspect, one way is to search for bugs filed for the same component, also try to rephrase your search, and concentrate on ''actions'' and ''words that describe'' the items involved to reproduce this crash.
Line 12: Line 57:
 * Hard ones:
  * [http://bugzilla.ubuntu.com/show_bug.cgi?id=17858 plug:spdif on emu10k1 gone after breezy upgrade]
 * More difficult ones:
  * [http://bugzilla.ubuntu.com/show_bug.cgi?id=17858 plug:spdif on emu10k1 gone after breezy upgrade] is a duplicate of
Line 16: Line 61:
If you can't find it in the list of open bugs, you could try to find it in the list of closed ones. Don't feel discouraged, if you don't find duplicates fast in the beginning, after some time you will know the usual suspects. If you can't find it in the list of open bugs, you could try to find it in the list of closed ones. Don't feel discouraged, if you don't find duplicates fast in the beginning, after some time you will get to know the usual suspects, and learn how to more easily identify them.

Please check any appropriate items in DebuggingProcedures before marking bugs as duplicates, as in some cases it is not as obvious as it might seem.

''Note:'' If you encounter a bug that has a terrible / unintelligible title, rephrase it, so people find it more easily.

== Reminder of the Code of Conduct ==

Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please
direct them to http://www.ubuntu.com/community/conduct

== Managing Status ==

As a reporter you usually don't have to take care of statuses. As a bug triager or developer it's an important tool to categorize bugs and have a good overview over the state of packages and software.

Here's a brief list and explanation of the various statuses:

 * '''Unconfirmed''':
  * Bugs start with this status,
  * Bugs marked {{{Unconfirmed}}} sometimes lack information, are not ready and are not confirmed yet, most of them are Untriaged at all
 * '''Needs Info''':
  * If you have to ask the reporter questions, please set this bug {{{Needs Info}}}
  * Ask the submitter to provide information in a comment, and make sure you subscribe to the bug so you will get the response.
  * a regular task for {{{Needs Info}}} bugs is to ask back, if there are no answers and after a reasonable stage (about a month), close them (as {{{Rejected}}} ) saying "If you have more information on this bug, please reopen."
 * '''Rejected''':
  * Bugs marked as {{{Rejected}}} are closed
  * Be sure to triple-check a bug before you reject it.
 * '''Confirmed''':
  * Bugs that are trivially reproduced, or have enough information attached that a developer can fix it.
  * {{{Confirmed}}} bugs require confirmation from '''someone other than the original reporter'''
  * This helps ensure that the bug is applicable to Ubuntu in general, and not a problem with the reporter's system, therefore...
  * Please don't confirm your own bugs!
 * '''In Progress''':
  * If you are working on fixing a bug, set it to {{{In Progress}}} so people know what's going on
  * Only the person to whom the bug is assigned should set this status
 * '''Fix Committed''':
  * Means for upstream projects, that the fix is in CVS/SVN/bzr or commited to some place
  * Means for package maintainers, that the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)
 * '''Fix Released''':
  * Means for upstream projects, that a release tarball was announced and is publically available
  * Means for package maintainers, that a fix was uploaded
   * Please don't be hesitant to add a changelog as a comment, so people know what to look out for

== Managing Importance ==

Please see ["Bugs/Importance"].

== Milestone ==

Don't change this field unless specifically instructed by a developer. In particular, do NOT use this field to record the release of Ubuntu in which the bug was observed: that is not its purpose! It is used by the release team when there is a reason to address the bug in a specific milestone release.

== Old Bugs ==

In many cases bugs reported in earlier versions are still open in our BTS. They may have been fixed upstream without it being noted in Malone or the design may have changed so that the issue is no longer relevant. If the bug does not represent a security issue or is otherwise critical, it is very unlikely that the fix will be back-ported to older versions of Ubuntu. When it is fixed in the development branch it is therefore most appropriate to mark it 'Fix Released'. This helps clear the BTS for old cruft.

----
Back to '''["HelpingWithBugs"]'''.[[BR]][[BR]]
[:CategoryBugSquad]

Overview

TableOfContents

The proper source package

Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in Ubuntu. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to Ubuntu. Some hints on finding the right package can be found in ["Bugs/FindRightPackage"].

The correct package for bugs in the Linux kernel is dependent upon the release of Ubuntu being used.

  • For Breezy (5.10) the correct package is linux-source-2.6.12
  • For Dapper (6.06) the correct package is linux-source-2.6.15
  • For Edgy (6.10) the correct package is linux-source-2.6.17
  • For Feisty (7.04) the correct package is linux-source-2.6.20

Confirming problems

If a bug is marked as Unconfirmed, it is helpful for you to try to reproduce the problem, and record the results in Malone. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment. Please do not confirm your own bugs - confirmation is required from someone other than the original reporter.

Forwarding bugs upstream

You can forward bugs to the authors of the software (upstream), if

  • you made sure that the bug doesn't occur because of Ubuntu related changes,
  • the change is too hard to be fixed by yourself or anyone else in the team.

To learn how to do this, please consult [https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7 The Forwarding section in the How to Triage Page].

How to Deal with Feature Requests

If you feel that the bug reported is a feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, ["SpecTemplate"] and http://launchpad.net/specs

How to deal with Support Requests

If you feel that the bug reported is a support request disguised as a bug report, please introduce the reporter gently to the Support Tracker we have. Be sure to mention http://launchpad.net/support

How to deal with suggestions for changing defaults

If you feel that the bug reported is a suggestions for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments.

Finding Duplicates

Finding duplicates of bugs is a very valuable contribution in the Bug community. Users sometimes don't know how to check if the same bug has already been filed, and sometimes they don't care. Weeding out simple ME TOO messages and aggregating information in one place is crucial to the process of fixing a bug.

There are quite a few measures you can take to assist with this aspect, one way is to search for bugs filed for the same component, also try to rephrase your search, and concentrate on actions and words that describe the items involved to reproduce this crash.

Examples:

If you can't find it in the list of open bugs, you could try to find it in the list of closed ones. Don't feel discouraged, if you don't find duplicates fast in the beginning, after some time you will get to know the usual suspects, and learn how to more easily identify them.

Please check any appropriate items in DebuggingProcedures before marking bugs as duplicates, as in some cases it is not as obvious as it might seem.

Note: If you encounter a bug that has a terrible / unintelligible title, rephrase it, so people find it more easily.

Reminder of the Code of Conduct

Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please direct them to http://www.ubuntu.com/community/conduct

Managing Status

As a reporter you usually don't have to take care of statuses. As a bug triager or developer it's an important tool to categorize bugs and have a good overview over the state of packages and software.

Here's a brief list and explanation of the various statuses:

  • Unconfirmed:

    • Bugs start with this status,
    • Bugs marked Unconfirmed sometimes lack information, are not ready and are not confirmed yet, most of them are Untriaged at all

  • Needs Info:

    • If you have to ask the reporter questions, please set this bug Needs Info

    • Ask the submitter to provide information in a comment, and make sure you subscribe to the bug so you will get the response.
    • a regular task for Needs Info bugs is to ask back, if there are no answers and after a reasonable stage (about a month), close them (as Rejected ) saying "If you have more information on this bug, please reopen."

  • Rejected:

    • Bugs marked as Rejected are closed

    • Be sure to triple-check a bug before you reject it.
  • Confirmed:

    • Bugs that are trivially reproduced, or have enough information attached that a developer can fix it.
    • Confirmed bugs require confirmation from someone other than the original reporter

    • This helps ensure that the bug is applicable to Ubuntu in general, and not a problem with the reporter's system, therefore...
    • Please don't confirm your own bugs!
  • In Progress:

    • If you are working on fixing a bug, set it to In Progress so people know what's going on

    • Only the person to whom the bug is assigned should set this status
  • Fix Committed:

    • Means for upstream projects, that the fix is in CVS/SVN/bzr or commited to some place
    • Means for package maintainers, that the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)
  • Fix Released:

    • Means for upstream projects, that a release tarball was announced and is publically available
    • Means for package maintainers, that a fix was uploaded
      • Please don't be hesitant to add a changelog as a comment, so people know what to look out for

Managing Importance

Please see ["Bugs/Importance"].

Milestone

Don't change this field unless specifically instructed by a developer. In particular, do NOT use this field to record the release of Ubuntu in which the bug was observed: that is not its purpose! It is used by the release team when there is a reason to address the bug in a specific milestone release.

Old Bugs

In many cases bugs reported in earlier versions are still open in our BTS. They may have been fixed upstream without it being noted in Malone or the design may have changed so that the issue is no longer relevant. If the bug does not represent a security issue or is otherwise critical, it is very unlikely that the fix will be back-ported to older versions of Ubuntu. When it is fixed in the development branch it is therefore most appropriate to mark it 'Fix Released'. This helps clear the BTS for old cruft.


Back to ["HelpingWithBugs"].BRBR [:CategoryBugSquad]

Bugs/CommonTasks (last edited 2011-06-15 18:35:14 by c-98-246-63-231)