Outil de suivi des anomalies

From Second Life Wiki
Revision as of 03:52, 2 October 2008 by Zai Lynch (talk | contribs) (help header)
Jump to navigation Jump to search

Emblem-important-red.png Avertissement

La traduction de cet article est obsolète. Pour accéder au contenu le plus récent, veuillez vous reporter à la version anglaise.

Si vous le souhaitez, vous pouvez participer à la mise à jour de la traduction de cet article en vous inscrivant à la page Community Translation Project. set version=2

Update Needed

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!

JIRA.jpg
Open Source Portal


 : Travail de traduction de cette page en cours :


Tout d'abord, deux choses à noter:

  • Le Traqueur d'issues JIRA n'est pas pour les demandes de support techniques. Si vous cherchez l'aide spécifique de compte, utilisez s'il vous plaît nos ressources de support support resources.
  • Toutes les soumissions au site (JIRA inclus) sont gouvernées selon Second Life Project Contribution Agreement. En soumettant des pièces et d'autres informations en utilisant ce site, vous admettez que vous avez lu, avez compris et avez été d'accord avec ces termes.

Le traqueur d'issues public JIRA, localisé à http://jira.secondlife.com, est une base de données recherchable utilisée pour organiser des issues (c'est-à-dire les bugs et les demandes caractérisées) soumis par la communauté de Second Life. Ici, vous pouvez aider à fournir des informations sur les issues que vous trouvez en utilisant les versions source ou standard ouvertes de Second Life. Les informations sur cette page vous aideront à devenir familiers avec le JIRA.

Plus précisément, JIRA est un instrument d'administration et d'édition de projet fait par Atlassian. Il est essentiellement utilisé par la communauté open source de Second Life et peut être considéré comme le "JIRA Public", "PJIRA", ou juste "JIRA", selon le contexte.

Comment il fonctionne

Il y a deux types principaux d'issues : l'annonce de bugs et les nouvelles caractéristiques.

  • Un rapport de bug est composé d'une description du problème et, si c'est possible, une façon de le reproduire.
  • Une nouvelle demande de caractéristique est composée d'une description et comment la caractéristique proposée devrait fonctionner.

Les deux types d'issues reçoivent alors l'attention d'autres utilisateurs, qui peuvent ajouter d'autres informations ou des descriptions plus simples et des reproductions. Les issues populaires accumulent des votes d'autres utilisateurs. Les programmeurs dans la communauté open source peuvent attacher "des éléments correctif", ou changer le code source qui adresse l'issue. Les votes, aussi bien que les événements comme le bug triages, aident à donner des priorités aux issues. Celles qui sont admises sont "importés" dans la copie privée des Lindens de JIRA.

Après que l'issue ai reçu l'attention de Linden, d'autres peuvent toujours continuer à aider :

  • Dès que les changements sont accomplis et en attente de proposition au public, le bug est résolu comme "Fixe en Attente".
  • Quand le changement a été rendu disponible, il est résolu comme "Fixé".
  • Généralement, après être confirmé comme fixé par Linden Lab Quality Assurance Team et notre communauté, son statut est changé "Resolu" à "Fermé".

En plus de "Fixe en Attente" et "Fixé", une issue peut aussi être résolue ou fermée si elle a son double dans une autre issue, non reproductible, mal classée, pas un bug, incomplète, etc.

La création de rapport de bug et les demandes de caractéristique

Si vous vous sentez perdus et ne savez pas où commencer, regardez cette vidéo:

<videoflash>Jofq8ClPfNg</videoflash>

Vous pouvez aussi voir le guide pour démarrer facile, "How to report bugs better".

Changements récent

Vous pouvez vérifier les Release Notes ou Beta Release Notes pour voir l'actualité des changements récents de Second Life. Quelquefois, on peut découvrir le contexte autour d'un nouveau bug, ou constater qu'un changement était voulu. Par exemple, l'incapacité de vendre votre terrain pour 0 L$ est une caractéristique, pas un bug.

Aussi, vous devriez vous assurer que vos pilotes vidéos sont à jours. Ceux-ci sont normalement obtenus depuis le site Internet de votre fabricant de matériel graphique, habituellement le NVIDIA official site ou le ATI official site. Le Omega Driverssont souvent des versions utilisées et modifiées de ces pilotes.

Determine if the issue has already been submitted

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 issue, especially since more-active issues get 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 (unfixed or untested) issues within each project, then begin a text search from there (by editing the filter). Of course you may create and save your own filters at any time, or 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 another way to reproduce the bug
  • Vote for the issue to express that you feel it is important.

The more good information there is about a specific issue, the better chance it has for a quick resolution.

Guidelines

  • 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, contact a Linden in the group "Bug Hunters", and e-mail your report to security@lindenlab.com. See the article on security issues.
  • If your issue is urgent (such as lost content), and you have a Premium Account use the phone or live text support. You might get a faster response if you also submit a ticket through the support portal, but usually it take over seven days before your ticket is opened.
  • When describing the bug, if possible, try to omit Resident names or other personally-identifying information. If the bug seems to affect only yourself or very few people, you should consider other ways to find technical support via the support portal.
  • The easier we can reproduce the bug, the more quickly it can get fixed. For example, instead of saying "I crash when I upload random things", the reproduction should be laid out in specific steps:
    Example:
    • Click File > Upload Image ($L10)...
    • Choose a .TXT file instead of a .JPG file
    • Click the Open button
Try sending your writeup to a friend, to see if they can follow it! If your friend can follow the steps, chances are we can too!
  • Consider uploading snapshots, images, videos, crash logs, or any other related files (10MB limit each). In the above example, you might consider uploading the files you tried to upload that caused the crash.
  • Do not submit more than one issue in a single report.
  • Do search through issues first to ensure yours is not a duplicate.

Submitting a bug

To create a new bug in JIRA, 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.
    • Reminder: you should submit security-related issues directly to the security team. See security issues.
  • Select "Bug" as your issue type.
  • Click "Next".

On the last page:

  • Enter a concise but descriptive summary (title) for the issue
  • Select the priority (severity) of the bug. For example, a "blocker" bug might render the program useless, but a "small" bug might be merely cosmetic. Click the 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.
  • The Linden Lab Issue ID should generally be left blank unless you are a Linden. If you want to reference a support ticket number, that should go in the description, not here.
  • Describe the environment in which the problem occurs, if you have noticed that the bug only occurs with certain hardware or software configurations. One way to find such information is the About box inside Second Life. You can guesstimate whether certain facts might be relevant (such as graphics card model for graphics problems, or headset models for voice features) and look for further help in narrowing things down. If configuration doesn't seem to 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 to reliably reproduce the bug (how to make the bug happen), or at least a description of what seems to lead to the bug, in some detail. 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)
    • Anything else which you think might help, such as forum links or blog posts.
    • Again, 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 provide 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.

Submitting 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 "reproduction", clearly describe the desired implementation and functionality of the new feature. Make sure it hasn't already been done — you can refer to release notes for historical context and read our blog to learn more about what we're doing next.

Voting for issues

You can vote for new features and bugs that you wish to see resolved, 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 can readily be used as part of our prioritization process. Note that since we need to look at aspects such as feasibility and the time required for implementation, 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, so reviewing all of your created/commented issues regularly will be useful while email support in JIRA is disabled.

Also, when issues are resolved internally the external site will be updated as well, so check your issues for changes on a regular basis.

Issue States

Available states

Here is how Linden Lab is using the resolutions:

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 reporter 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".
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.
Won't Fix
means that the assignee doesn't believe this issue should ever be fixed.
Duplicate
means that there's some other issue that describes the same problem/idea.
Needs More Info
this issue lacks information
Cannot Reproduce
we're applying this label pretty liberally. Please provide a 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 issue tracker.
Closed
The final resting place.

What's the difference between the "Fixed" and "Fix Pending" resolutions?

It's simple:

  • "Fixed" means the fix is available in the live Second Life release, right now.
  • "Fix Pending" means the fix has been made within Linden Lab and has not been released publicly yet. It may need to undergo extra care, like quality assurance, or requires merging from a branch, before being available to you. Think of it as a "We're almost there... coming soon!" notice.

Second Life JIRA FAQ

Caveats

  • The JIRA Issue Tracker is not for technical support, so please do not enter issues which would require a response tailored to your individual situation. Examples include:
    • "I can't change my tier"
    • "I have a question about the land I bought"
    • "I lost part of my inventory"
    • "I keep crashing!"
    • "Someone stole my L$"
    • "The sim I'm in is LAGGIN BAD"
    • "How do I build a house?"
    • More examples of misfiled issues
    The people who use the JIRA usually can't do anything about these kinds of issues, and it will most likely be a waste of time (you'll likely get only a "please contact support" reply). It also makes it harder for your fellow Residents to use the Issue Tracker. If you're looking for personal assistance, please send your message to the right place by contacting Support, and be sure to include useful details to help Linden Lab help you.


  • Before reporting issues, you should first see if there is any existing information by searching the support resources, and look for the latest status reports on the Official Linden Blog.


Note: The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker.


Examples of specific behavior or actions which may result in removal from the Issue Tracker:

  • Using the Issue Tracker to promote your 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 Issue 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. Pjira is about finding solutions to issues. 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 Pjira.

Logging in

  • Visit https://jira.secondlife.com and click the 'Log In' link on the top right of the page
  • On the login page, enter your Second Life username and password.
  • This will now load the main Jira page you saw before but it will have more options, like "Create Issue", a link to edit your profile, and some pre-defined filters.

Bugs & New Features

  • You may wish to look through Bug Reporting 101 for things to try before submitting a bug.
  • You can also propose new features through JIRA. (JIRA is the successor the Feature Voting Tool, because it has better search and parallels the way the Lindens internally organize issues. Plus, you can discuss with other Residents.)

User profile

  • Each JIRA user has a profile. The profile consists of your Username (SL name), Fullname (in our case, also your SL name), and all of the JIRA groups you belong to. For most people, this means "jira-users."
  • The email address associated with your account shall remain anonymous to other users. The address is not visible or configurable at this time. Direct import of your email address from Second Life's database is currently disabled.
  • The JIRA profile is not editable because allowing changes would introduce conflicts with your Second Life account. If you wish to edit account information such as your email address, please login to the account management page at secondlife.com.

Customizing preferences

  • If you want to show more issues per page or change the language JIRA's displayed in, Update User Preferences after logging in.

Projects and Components

  • Projects are used to categorize issues into logical groups.
  • Components are used to specify which part of a system the issue affects. In other words, what is the scope of the problem within a project.
Projects and Components in JIRA
Viewer (VWR) Service (SVC) Website (WEB) Miscellaneous (MISC)
  • Avatar/Character
  • Building (in-world)
  • Chat/IM
  • Crashes
  • Documentation
  • Graphics
  • Internationalization
  • Inventory
  • Land
  • Linden Dollars (L$)
  • Missing Content
  • Performance
  • Permissions
  • Physics
  • Scripting
  • Sound
  • Source Code
  • Stipends
  • User Interface
  • Voice
  • HTTPRequest
  • Internationalization
  • Performance
  • Physics
  • Scripts
  • Simulation
  • Teleport
  • XML-RPC
  • Account summary
  • blog.secondlife.com
  • Developer Directory
  • Events
  • forums.secondlife.com
  • Friends Online
  • Interactive map
  • jira.secondlife.com
  • Land Store
  • lindenlab.com
  • Lindex
  • New account creation
  • Public Data Feeds
  • Public Metrics & Charts
  • secondlife.com
  • teen.secondlife.com
  • wiki.secondlife.com
  • Miscellaneous
Second Life Viewer (VWR)
Issues pertaining to the Second Life viewer are reported under this project.
Examples:
  • "My avatar clothing is all black after installing a video driver update" (Component = Avatar/Character)
  • "Objects in my Inventory do not remain sorted in the correct order after logging out and back in again" (Component = Inventory)
Second Life Service (SVC)
Issues pertaining to the Second Life service are reported here.
Examples:
  • "Server performance decreases when several avatars teleport into the region at once" (Component = Performance and/or Teleport)
  • "My scripted objects are not able to talk to the outside world after Second Life grid downtime" (Component = Scripts).
Second Life Website (WEB)
Issues pertaining to the Second Life website are in this project.
Examples:
  • "Wiki prevents login for users with a dash in their name" (Component = wiki.secondlife.com)
  • "jira.secondlife.com always forces me to authenticate even if I save my login information" (Component = jira.secondlife.com).
Second Life Miscellaneous (MISC)
Any other type of issue should be reported in the MISC project.
Example:
  • "The TOS does not allow me to edit the viewer source code" (Component = Miscellaneous)

Security Issues -- a.k.a "the missing Fifth Project"

The Security project in Jira is only accessible by Linden employees. However, you can create a new issue there, and the security team will get immediate notification. See security issues page for more information about submitting issues and collecting bounties for responsibly reporting valid security issues.

Who is WorkingOnIt Linden?

When an issue is being worked on, it may be assigned to "WorkingOnIt Linden" to mark its status. Any Linden has access to the account. See User:WorkingOnIt Linden for details.

Found a bug on JIRA itself!

When you found a bug or other problem (including feature request) on the JIRA itself, Lindens want you to file it on the JIRA run by Atlassian (the developer of JIRA software) by yourself, not thgough the SL public JIRA. It is available on http://jira.atlassian.com

Lindens also want you to put a link to the issue you filed here if you do so.

But what does JIRA mean?

Err... it means “Godzilla”. No, really.

Searching

Watch this video tour: <videoflash>SAlXK5hSVMc</videoflash>

Parameters

Perform a search

  • First, click on the "Find Issues" link at the top of the screen.
  • Next, enter the parameters you wish to search for in the search pane on the left-hand side of the screen.
  • As an example, if I wish to search for issues that have not been resolved containing the word "avatar", I would choose the following parameters:
    • Project = all projects
    • Text search = avatar
    • Resolutions = Unresolved
  • Another sample search would be for any issues that are fixed in the last week in a particular project. For example, I want to find all bugs in the Second Life Viewer project that were resolved between February 1, 2007 and February 14, 2007. I would enter the following parameters:
    • (Optional: Click the "New" link in the search pane to clear settings from any previous searches)
    • Project = Second Life Viewer
    • Resolution = Fixed
    • Updated After = January 31, 2007
    • Updated Before = February 15, 2007

Saving a search as a Filter

  • A search filter is a saved search that you may share with others.
  • After performing a search as described above, you may save it as a filter by clicking the "Save" link in the Search pane.
  • Name the filter something meaningful, for example "Unresolved avatar bugs in all projects."
  • Now you can access the search and run it at any time by clicking the "Filter" link in the top right-hand side of the page. This saves time and effort, especially if you frequently run the same complex search and want a handy shortcut!

How do I help out?

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.

Related resources

Want to learn more about our Issue Tracker?

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Outil_de_suivi_des_anomalies&oldid=94196"