Bug Tracker/ko
|
Warning! |
|
This article contains an outdated translation. Please refer to the English version to access the latest updated content. If you would like to help updating the translation of this article, please join the Community Translation Project. set version=2 |
This article needs an update to reflect recent changes in the base article located at Issue tracker. When you're done with the update, change the {{Help/CODE|Parent=Issue tracker|BugFixes=*}} part to {{Help/CODE|Version=2|Parent=Issue tracker|BugFixes=*}}. Thank you for your help!
First, two notes:
| |||||||||
| |||||||||
The Public Bug Tracker is located at http://jira.secondlife.com. It is a searchable database used to organize issues (i.e. bugs and feature requests) submitted by the Second Life community. There, you can help to provide information about issues you find when using the open source or standard versions of Second Life. The information on this page will help you become familiar with this tool.
More precisely, JIRA is an issue-tracking project management tool made by Atlassian. It is primarily used by the Second Life open source community and may be referred to as the "Public JIRA", "PJIRA", or just "JIRA", depending on the context.
How it works
There are two main types of issues: bug reports and new features.
- A bug report is composed of a description of the problem AND a way to reproduce it.
- A new feature request is composed of a description and how the proposed feature should work.
- Both types of issues then get attention from other Residents, who can add better or simpler descriptions and reproductions.
- Popular issues will accumulate Votes from other residents.
- Programmers in the open source community can attach "patches", or changes to the source code which address the issue.
- Votes, as well as events like bug triages, help prioritize the issues.
- Those issues which are acknowledged by Linden Lab are "imported" into the Linden Lab internal copy of JIRA. This means a bug will be investigated and worked on.
After the issue gets Linden attention, others can still follow along what is the status of the issue:
- Once the changes are completed and awaiting release to the public, the bug is resolved to show "Fix Pending".
- When the change is available in a new version of Second Life, it is resolved as "Fixed".
- Generally, after being confirmed as fixed & done by Linden Lab's Quality Assurance Team and our community, the status is changed from "Resolved" to "Closed".
In addition to "Fix Pending" and "Fixed", an issue can also be resolved if it appears to be a Duplicate of another issue, Unreproducible, Misfiled, not a bug, incomplete, etc.
Create a bug report / feature request
If you feel lost and don't know where to begin, watch this 15-minute video tour:
- <videoflash>Jofq8ClPfNg</videoflash>
Guidelines for a bug report
|
Stay up-to-date
- You can check the Release Notes to stay current with recent changes to Second Life. Sometimes, you can discover the context around a new bug, or find that a change was intentional. For example, not being able to sell your land for L$0 is a feature, not a bug!
- Also, you should make sure your video drivers are up to date. Hint for advanced users: The Omega Drivers are often-used modified versions of those drivers.
Determine if the issue has already been submitted
Before reporting issues of widespread system breakage, you should first see if there is any existing information by searching the support resources, and look for the latest status reports on the Status Reports page.
Avoiding duplicate issues is very important. Sorting through duplicates wastes time and effort (for both Linden Lab staff and fellow residents), and it causes bugs and feature proposals to seem like they are getting less attention than they actually are. It is more effective to concentrate efforts about the same problem in the same reported issue, especially since more-active issues receive greater priority.
After logging in, you will see the Dashboard. Here you have access to some search filters which give you access to the most up-to-date information on submitted issues. For example, you can click on ones which show all unresolved issues within each project, then begin a text search from there (by editing the filter). Of course you may simply run a new search from the Quick Search: box. Either way, it is best practice to search for issues you wish to report in several ways before submitting them!
- If you find that your issue was already submitted, you can still do several things to help:
- Leave a comment containing additional information or details
- If it's a bug, possibly explain another way to reproduce the bug
- Vote for the issue to express that you feel it is important.
- The more good, SPECIFIC information there is about an issue, the better chance it has for a quick resolution.
- If you find that your issue was already submitted, you can still do several things to help:
To submit a bug
To create a new bug, do the following:
- Click the "Create New Issue" link in the blue navigation bar towards the top of the screen. (If you don't see this, make sure you are logged in to JIRA.)
- On the first page:
- Select a Project that most closely matches the kind of bug you are submitting - see Projects and Components.
- Select "Bug" as your Issue type.
- Click "Next".
- On the second page:
- Enter a concise but informative summary (title) for the issue
- Select the priority (severity) of the bug. For example, a "Showstopper" bug might render the program useless, but a "small" bug might be merely cosmetic. Click the Help icon next to the dropdown for more details.
- Select components that narrow the scope of the bug. You can select multiple components by Ctrl-clicking.
- Choose the versions that the bug effects. You should only select those versions where you have observed the bug, and only select a "First Look" version if the bug only applies to First Look.
- Describe the computer environment in which the problem occured. For example, if you have noticed that the bug only occurs with certain hardware or software configurations.
- The best way to report this information is to paste the info that comes from inside Second Life viewer. (Help menu > About Second Life...) Certain facts might be relevant (Windows vs Mac vs Linux machine, or graphics card model, or headset models for voice features). If configuration truly doesn't matter, you can leave it blank.
- For example, "Only happens with Mac OS X 10.4.1," or "Seen only with NVIDIA GeForce Go 7800 card," etc.
- Enter a detailed description of the issue, and be sure to include:
- Steps (1,2,3...) to reliably reproduce the bug-- How to make the bug happen. If you cannot identify the specific steps, describe what seems to lead to the bug. Try to make this as simple as possible while still being specific enough to reproduce the bug. Simpler reproductions make it easier to narrow down the causes.
- OBSERVED results (what happens when the bug occurs)
- EXPECTED results (what behavior you would have expected instead)
- As a reminder: be as detailed as possible without including personal information!
- If you have a screenshot or video of the bug, or any other relevant file, you can attach it under attachment. Note that it has a 10MB size limit per file. You can also attach additional files later. (See Debug Help for various ways to hunt for such additional information.)
- If you are a programmer and are attaching a patch for the source code, enter the source version the patch is against and check the patch attached box.
- Finally, click "Create" to create the new issue.
To submit a new feature
The process is similar to submitting a bug, with the following differences:
- Select "New Feature" instead of "Bug" as your Issue type.
- Instead of a description how to reproduce, instead clearly describe the desired implementation and functionality that you would like in the new feature. Make sure it hasn't already been done — you can read our blog to learn more about what we're doing next.
To submit a Security Issue!
- Please submit security-related issues and exploits directly to the security team. ("Exploits" are bugs that could be used to get an advantage over others, unauthorized access to scripts, unauthorized copying or transferring or modifying of objects that you didn't create (also called 'permissions bugs'), and other bugs that could potentially cause a compromise of the grid or a resident's privacy.)
- For the fastest results, e-mail your security report to security@lindenlab.com. See the article on security issues.
Be courteous
Note: The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Bug Tracker. Any Resident who disregards these guidelines may be banned from future use of the Bug Tracker.
Examples of specific behavior or actions which may result in removal from the Bug Tracker:
- Using the Bug Tracker to promote a business, cause, blog, website or anything not directly related to the issue at hand.
- Flaming - The act of posting a message that is intended to incite anger or directly attack a person or persons is called "Flaming" and it not appropriate for the Bug Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.
- Private Discussions - Blogging your personal opinions or off-topic rants. The Bug Tracker is about finding solutions to bugs and problems. We love productive feedback. Please stick to the technical details of the matter at hand.
- Editing Wars - Repeated changes to a resolution, priority or classification of an issue within the Bug Tracker.
Vote for issues
You can vote for new features and bugs that you wish to see fixed by Linden Lab, and view all issues by # of votes. JIRA uses approval voting, so you can vote for as many (or few) issues as you'd like, and you get 1 vote per issue.
Votes are readily used as part of our prioritization process. Note that since we need to look at aspects such as feasibility and the time required for development, a highly-voted issue isn't necessarily going to be resolved ahead of a lesser-voted, but more doable one.
Return to check on issue status
Linden Lab will review issues submitted to jira.secondlife.com on a regular basis. The engineering team may require additional information from the issue reporter, or other contributors. Check back to see if your issue has received comments or questions from Linden Lab.
When your issue has been fixed internally, it will be updated as well in the Bug Tracker (even before it is ready to ship in a new version). So check your issues for changes on a regular basis.
Status of your Issue
Available states
Here is how Linden Lab uses the various resolution states:
- Open
- This is an issue that belongs to the Assignee to resolve. The Assignee may fix the issue, or kick the issue back to the person who reported it, by marking it "Resolved" (see below)
- In Progress
- This is how a developer signals to everyone that he/she is working on the issue.
- Reopened
- same as "Open". Even though it was closed before, it is now reported as still a problem that needs attention.
- Resolved
- This is an implicit assignment back to the reporter of the issue. It is not closed yet, but rather in a state of limbo that depends on the resolution. It's up to the Reporter to decide whether to reopen an issue, or close it.
- Fixed
- means that the bug is fixed in a public release of Second Life.
- Fix Pending
- means that the bug is fixed in a version of the code that should soon be publicly available.
- Contact Support
- the issue in the Pjira is one that needs to be handled through the support team and the resident needs to fill out a support ticket.
- Won't Finish
- means that the assignee or Linden Lab doesn't believe this issue should or will be fixed in any foreseeable future.
- Duplicate
- means that there's some other issue that describes the same problem/idea.
- Expected Behavior
- the issue being discussed is not a bug and functions as it does by design.
- Needs More Info
- this issue lacks enough information. Please add that information or it CANNOT be investigated further.
- Under Advisement
- this is used by Linden Lab for issues that tend to fall more in the category of Policy rather than being just a technical bug. This is used to let the community know that the Pjira has been viewed and is being discussed.
- Cannot Reproduce
- this means that following the stated steps still does not show the problem. Perhaps there is additional settings/actions or factors that need to be true in order for the problem to occur. Please provide an even more detailed description of how to reproduce a problem. Issues that can't be reproduced will eventually be closed.
- Misfiled
- this issue doesn't belong in this Bug Tracker.
- Closed
- The final resting place. It's done!
Frequently Asked Questions
See the Bug Tracker/FAQ for answers to common questions!
Searching
See the Bug Tracker/Searching page for more help!
How can I help Linden Lab track its bugs?
Glad you asked!
Marking Duplicates
If you notice an newer issue that is a duplicate of an existing issue with a lot more comments, patches, or votes, feel free to choose "Resolve" and choose "Duplicate". But when you do this, please also choose "Link", and then say "This issue duplicates" and enter the main bug number. This lets everyone keep track of which bugs are duplicates of each other, and which bugs are reported more than others. This ensures that bugs that are often reported get the most attention, and also allows the duplicates to be reviewed from one central location, to ensure they are truly duplicates.
Resolving support issues
This one is best left to technically adept users that can spot the difference between a support issue and a bug -- it's not always a simple matter to figure out. You should at most "Resolve" a report that seems to be a support issue. "Resolving" an issue puts the responsibility back on the reporter to provide more information on why the report isn't a support issue, and is indeed a reproducible bug that an entire class of user experiences.
Resolving bugs that you can't reproduce
If you do exactly what they say in the bug, with the same environment, and can't reproduce the bug, you should resolve the bug. Be careful, if a bug is related to graphics rendering, and you do not have the same video card, for example, that is not the same environment and you can't make this determination. Again this is also best left to technically adept users.
Reproducing bugs
This one is very important! If you can create a step-by-step list to reproduce the bug in the bug report, this helps Linden Lab concentrate on bugs that can be verifiably fixed. Unless a bug can be reproduced, it is impossible to know if it has been fixed or not. Do what the bug reporter said they were doing, write a detailed step-by-step list of things you did to cause the bug to happen, and add it to the bug saying that you have successfully reproduced the bug. Such bugs with solid reproductions get higher priority in the development process, and help the Bug Triage Team work more efficiently.
Sorting issues in the wrong categories
If an issue is in the wrong category (i.e. a VWR issue that belongs in SVC) it should never be resolved as "misfiled." Instead, a comment should be left on WEB-566 listing the issue and where it should be belong. A JIRA volunteer will make sure it gets moved to the appropriate place.
Related resources
Want to learn more about our Bug Tracker?
- Bug Tracker Forum Transcript - Info from Rob and Aric Linden on why we have an Bug Tracker, its behind-the-scenes workings, and answers to various questions.
- JIRA user's guide by Atlassian, creaters of JIRA