CommonTasks

Differences between revisions 29 and 71 (spanning 42 versions)
Revision 29 as of 2006-05-04 00:14:20
Size: 8718
Editor: studiocity-motorola-bsr1-70-36-194-85
Comment: hardware-related guidelines
Revision 71 as of 2011-06-15 18:35:14
Size: 7918
Editor: c-98-246-63-231
Comment: Its always linux now
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from Bugs/CommonTasksDraft
== Overview ==
<<Include(BugSquad/Header)>>
Line 4: Line 3:
[[TableOfContents]] ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 6: Line 5:
== The proper source package == == Common Tasks of Bugsquad ==
Line 8: Line 7:
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 linux, regardless of which particular package is in use (there are many packages which contain Linux kernels).
Here we have a list of common tasks performed by BugSquad members. Feel free to jump in with whatever looks interesting. For a more detailed explanation of what is involved in triaging, please see [[https://wiki.ubuntu.com/Bugs/HowToTriage|How To Triage]]. If you have any more specific questions don't hesitate to join #ubuntu-bugs on [[IRC]] (irc.freenode.net) and give a shout.
Line 13: Line 10:
== Confirming problems == === Finding the proper source package ===
Line 15: Line 12:
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. 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]].

=== Confirming problems ===

If a bug is marked as New, it is helpful for you to try to reproduce the problem, and record the results in Launchpad. 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. When confirming the bug be sure to indicate which version of the package you used. One way to get the package version is via {{{dpkg -l $pkgname}}} where {{{$pkgname}}} is the name of the package you are testing.

'''Note:''' Do not confirm your own bugs - confirmation is required from someone other than the original reporter.
Line 18: Line 21:
== Forwarding bugs upstream == === Forwarding bugs upstream ===
Line 20: Line 23:
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.
You should 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 bug report is complete.
Line 24: Line 27:
If you do this, be sure to
 * include all the necessary information, such as
  * how to reproduce the bug
  * which version is used (which version of dependent libraries, if the bug indicates problems there)
  * who reported it
  * where the whole conversation can be found
 * create a bug watch in Malone for this
To learn how to do this, please consult [[https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding%20upstream|HowToTriage/ForwardingUpstream]]
Line 32: Line 29:
== How to Deal with Feature Requests == === How to deal with Feature Requests ===
Line 34: Line 31:
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 If you feel that the bug reported is a non-trivial 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
Line 37: Line 34:
== How to deal with Support Requests == === How to deal with Support Requests ===
Line 39: Line 36:
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 If you feel that the bug reported is a support request disguised as a bug report, please gently introduce the reporter to the Support Tracker located at http://answers.launchpad.net/ubuntu/ .
Line 42: Line 39:
== How to deal with suggestions for changing defaults == === How to deal with suggestions for changing defaults ===
Line 44: Line 41:
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. If you feel that the bug reported is a suggestion 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.
Line 46: Line 43:
=== Duplicates ===
Line 47: Line 45:
== Finding Duplicates == Many of the reports filed against Ubuntu are actually duplicates of bugs already reported. This can happen after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, reporters don't know how to check if the same bug has already been filed, or it is hard for them to determine if their bug is the same as another. Finding these duplicate bugs and aggregating information in one bug report is a very valuable contribution.
Line 49: Line 47:
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. Bugs are duplicates when they have the same root cause. Determining this is a skill that you'll pick up as you become more familiar with a particular package or subsystem. Bugs are ''not'' necessarily duplicates if they have the same effects. For example, many different bugs can cause X not to start. Determining which bug a particular report refers to is part of triaging. If in doubt, ask for a second opinion. It is probably also sensible to ask the reporter to take look at the possible duplicate and to help with the decision. Reporters are normally interested in helping with their own bug reports!
Line 51: Line 49:
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. '''For the above reason, bugs filed on the "linux" package should not be marked as duplicates.'''
Line 53: Line 51:
Examples: When you first look at a new bug, try to find an existing bug in the system that describes the new one. Here's how:
Line 55: Line 53:
 * Easy ones:
  * [http://bugzilla.ubuntu.com/show_bug.cgi?id=18808 DAAP support] is a duplicate of
   * [http://bugzilla.ubuntu.com/show_bug.cgi?id=18733 please enable daap]
 * More difficult ones:
  * [http://bugzilla.ubuntu.com/show_bug.cgi?id=17858 plug:spdif on emu10k1 gone after breezy upgrade] is a duplicate of
   * [http://bugzilla.ubuntu.com/show_bug.cgi?id=15585 Muted sound after dist-upgrade from Hoary to Breezy]
   
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.
 * Click the "List open bugs" link at the bottom of the bug page '''or'''
 * Click the "Bugs" tab at the top of the page
  * Both ways will produce a list of bugs about the same package
 * Look for bugs with similar descriptions or related titles.
 * If they describe the same root cause, decide which report should be the primary one. This should be the one that's the most understandable and contains the most information, not necessarily the oldest (lowest numbered) bug.
 * For the other report, add a comment like this standard reply <<Include(Bugs/Responses, , from="^== A duplicate ==$", to="^==")>>
 * Then click the "Mark as Duplicate" link at the top left of the bug report page, and enter the number of the primary bug.
Line 64: Line 61:
''Note:'' If you encounter a bug that has a terrible / unintelligible title, rephrase it, so people find it more easily. By default, searches in Launchpad and mentioned above will only look at {{{Open}}} bugs. It may also be worthwhile to go through the list of {{{Invalid}}} and {{{Won't Fix}}} bugs which you can look for by using an "Advanced Search". There is also a standardized tag for bugs likely to have lots of duplicates -- [[https://launchpad.net/ubuntu/+bugs?field.tag=metabug|metabug]].
Line 66: Line 63:
== Reminder of the Code of Conduct == When marking a bug report as a duplicate of another (master) bug report, please also check whether the master bug report is marked as private. If so, the master bug report might not be visible to the current bug reporter. When the parent bug is indeed marked as private please check why it is so. If it's only private because apport makes all bugs private by default, but the coredump has been removed and none of the apport attachments contain anything private, it may be made public. If it does contain confidential information, the bug should remain private and it is better to search for another bug which could be safely marked as the master bug. For any guidance regarding the private status of a master bug and marking another bug as a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs).

=== Reminder of the Code of Conduct ===
Line 71: Line 70:
== Managing Status == === Setting Status ===
<<Include(Bugs/Status, , ,from="Header.*$", to="^----")>>
Line 73: Line 73:
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. === Setting Importance ===
<<Include(Bugs/Importance, , ,from="Header.*$", to="^----")>>
Line 75: Line 76:
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}}}
  * a regular task for {{{Needs Info}}} bugs is to ask back, if there are no answers and after a reasonable stage, close them 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''':
  * {{{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 start working on a bug, set it to {{{In Progress}}} so people know what's going on
 * '''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
   * Alease don't be hesitant to add a changelog as a comment, so people know what to look out for

== Managing Severity ==

Ubuntu uses the following guidelines for assigning severity:
 * '''Wishlist''': a request to add a new feature to one of the programs in Ubuntu
  * These aren't really bugs, but ideas for new features which do not yet exist
  * If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications
 * '''Minor''': Bugs which affect functionality, but to a lesser extent than most bugs, for example:
  * Can be easily worked around
  * Only affects unusual configurations
 * '''Normal''': A functionality bug of the standard variety. Most bugs are of "Normal" severity, for example:
  * Has moderate impact on a core application
  * Has a severe impact on a non-core application
  * A problem with a non-essential hardware component (network card, camera, webcam, music player, sound card, etc.)
 * '''Major''': A bug which fulfills one of the following criteria:
  * Has a severe impact on a small portion of Ubuntu users (estimated)
  * Makes a default Ubuntu installation generally unusable for some users
   * For example, if the system fails to boot, or X fails to start, on a certain make/model of computer
   * A problem with an essential hardware component (disk controller, video card, keyboard, mouse)
  * Has a moderate impact on a large portion of Ubuntu users (estimated)
 * '''Critical''': A bug which has a severe impact on a large portion of Ubuntu users

== Milestone ==
=== Milestone ===
Line 125: Line 80:
== Old Bugs == === Old Bugs ===
Line 127: Line 82:
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. In many cases bugs reported in earlier versions are still open in our bug tracking system. They may have been fixed upstream without it being noted in Launchpad 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 bug tracking system for old cruft.
Line 130: Line 85:
Back to HelpingWithBugs Back to '''[[HelpingWithBugs]]'''.<<BR>><<BR>>
[[CategoryBugSquad]]

Common Tasks of Bugsquad

Here we have a list of common tasks performed by BugSquad members. Feel free to jump in with whatever looks interesting. For a more detailed explanation of what is involved in triaging, please see How To Triage. If you have any more specific questions don't hesitate to join #ubuntu-bugs on IRC (irc.freenode.net) and give a shout.

Finding 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.

Confirming problems

If a bug is marked as New, it is helpful for you to try to reproduce the problem, and record the results in Launchpad. 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. When confirming the bug be sure to indicate which version of the package you used. One way to get the package version is via dpkg -l $pkgname where $pkgname is the name of the package you are testing.

Note: Do not confirm your own bugs - confirmation is required from someone other than the original reporter.

Forwarding bugs upstream

You should 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 bug report is complete.

To learn how to do this, please consult HowToTriage/ForwardingUpstream

How to deal with Feature Requests

If you feel that the bug reported is a non-trivial 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 gently introduce the reporter to the Support Tracker located at http://answers.launchpad.net/ubuntu/ .

How to deal with suggestions for changing defaults

If you feel that the bug reported is a suggestion 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.

Duplicates

Many of the reports filed against Ubuntu are actually duplicates of bugs already reported. This can happen after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, reporters don't know how to check if the same bug has already been filed, or it is hard for them to determine if their bug is the same as another. Finding these duplicate bugs and aggregating information in one bug report is a very valuable contribution.

Bugs are duplicates when they have the same root cause. Determining this is a skill that you'll pick up as you become more familiar with a particular package or subsystem. Bugs are not necessarily duplicates if they have the same effects. For example, many different bugs can cause X not to start. Determining which bug a particular report refers to is part of triaging. If in doubt, ask for a second opinion. It is probably also sensible to ask the reporter to take look at the possible duplicate and to help with the decision. Reporters are normally interested in helping with their own bug reports!

For the above reason, bugs filed on the "linux" package should not be marked as duplicates.

When you first look at a new bug, try to find an existing bug in the system that describes the new one. Here's how:

  • Click the "List open bugs" link at the bottom of the bug page or

  • Click the "Bugs" tab at the top of the page
    • Both ways will produce a list of bugs about the same package
  • Look for bugs with similar descriptions or related titles.
  • If they describe the same root cause, decide which report should be the primary one. This should be the one that's the most understandable and contains the most information, not necessarily the oldest (lowest numbered) bug.
  • For the other report, add a comment like this standard reply

    Include: Nothing found for "^== A duplicate ==$"!

    information_little.png This page is part of the Bug Squad’s KnowledgeBase - pages with information about how to triage bugs.

    These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at:

    https://launchpad.net/~gm-dev-launchpad/+archive/ppa

    When you update one of these responses, you should also update the response used by the Firefox extension. These responses can be found in the bazaar branch lp:ubuntu-bugcontrol-tools in the file gm-xml-files/bugsquad-replies.xml. To check out a branch, use

    bzr branch lp:ubuntu-bugcontrol-tools

    Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see this email message), and they can be used when replying to a bug report if merged.

    Not described well

    Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

    We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures.

    At a minimum, we need:

    1. The specific steps or actions you took that caused you to encounter the problem.
    2. The behavior you expected.
    3. The behavior you actually encountered (in as much detail as possible).

    Please also ensure that you include the release and flavour of Ubuntu that you are using.

    Thank you!

    Missing Steps to Recreate Bug

    Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:
    * Is this reproducible?
    * If so, what specific steps should we take to recreate this bug?

    This will help us to find and resolve the problem.

    Missing Apport Information

    Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
    apport-collect BUGNUMBER

    When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

    Package or domain specific questions

    The following packages or type of bugs require the specific debugging information:

  • Then click the "Mark as Duplicate" link at the top left of the bug report page, and enter the number of the primary bug.

By default, searches in Launchpad and mentioned above will only look at Open bugs. It may also be worthwhile to go through the list of Invalid and Won't Fix bugs which you can look for by using an "Advanced Search". There is also a standardized tag for bugs likely to have lots of duplicates -- metabug.

When marking a bug report as a duplicate of another (master) bug report, please also check whether the master bug report is marked as private. If so, the master bug report might not be visible to the current bug reporter. When the parent bug is indeed marked as private please check why it is so. If it's only private because apport makes all bugs private by default, but the coredump has been removed and none of the apport attachments contain anything private, it may be made public. If it does contain confidential information, the bug should remain private and it is better to search for another bug which could be safely marked as the master bug. For any guidance regarding the private status of a master bug and marking another bug as a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs).

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

Setting Status

Include: Nothing found for "Header.*$"!

Include: Nothing found for "^----"!

Setting Importance

Ubuntu uses the following guidelines for assigning importance. The importance of the bug signifies the priority that it should be given by people fixing bugs.

In order to set the Importance field of a bug in Launchpad, you need to be a member of UbuntuBugControl either through direct membership or because of your membership in another team. The importance of the bug should be set as soon as possible.

The importance of a bug report can be modified by clicking on the current Status or Importance, in the yellow line and under the "Affects" column header, which will reveal a sub menu. You can then choose a new importance in the drop down box.

Here are the meanings of the different importance values:

  • Undecided: The default for new bugs. Also means that there is insufficient information to determine importance.

  • Wishlist: Missing functionality.

    • These aren't always bugs, but can be ideas for new features which do not yet exist.
    • These can also be requests to have software packaged for Ubuntu.
    • If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications.

    • These can be bugs that affect an experimental extension or non-essential feature of a given package/project.
    • Bugs that would only be fixed on a best-effort or outside-contribution basis might also be considered wishlist.

  • Low: Bugs which affect functionality, but to a lesser extent than most bugs, examples are:

    • Bugs that have easy work-arounds

    • Bugs that affect unusual end-user configurations or uncommon hardware
    • Bugs that affect a non-essential aspect and limited scope of the application
    • Bugs that have a moderate impact on a non-core application
    • Cosmetic/usability issues that does not limit the functionality of a non-core application
    • Non-ideal default configurations
  • Medium: Most bugs are of medium importance, examples are:

    • A bug that has a moderate impact on a core application.
    • A bug that has a severe impact on a non-core application.
    • A bug which impacts accessibility of a non-core application.
    • A usability issue that does not limit the functionality of a core application.
    • A problem with a non-essential hardware component (removable network card, camera, webcam, music player, sound card, power management feature, printer, etc.)
  • High: A bug which fulfills any of the following criteria:

    • Has a severe impact on a small portion of Ubuntu users (estimated)
    • Makes a default Ubuntu installation generally unusable for some users
      • For example, if the system fails to boot, or X fails to start, on a certain make and model of computer
    • A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse)
    • Has a moderate impact on a large portion of Ubuntu users (estimated)
    • Prevents the application or any dependencies from functioning correctly at all
    • Renders essential features or functionality of the application or dependencies broken or ineffective
    • Impacts accessibility of a core application
  • Critical: A bug that has a severe impact on a large portion of Ubuntu users

    • Causes data corruption
    • Crashes the entire operating system
      • For example, if the system fails to boot, or X fails to start, on various makes and models of computer
    • Renders the system temporarily or permanently unusable
    • Severely affects applications beyond the package responsible for the root cause

If you're not yet an Ubuntu Bug Control member, you'll have to ask someone who is to do it for you. Paste the bug number in #ubuntu-bugs channel at FreeNode and say you think the bug should be set to importance 'Wishlist / Low / Medium / High / Critical'. Someone will notice your comment and set it for you, although not necessarily immediately.

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 bug tracking system. They may have been fixed upstream without it being noted in Launchpad 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 bug tracking system for old cruft.


Back to HelpingWithBugs.

CategoryBugSquad

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