How to use the issue tracker

From CyanogenMod Wiki

Jump to: navigation, search

The issue tracker, unlike the xda-dev forums, is NOT the place for user help. The issue tracker's purpose is to identify problems with CyanogenMod itself, and make Cyanogen's life easier. Cyanogen (steve.kondik on the tracker) has final say on all issues, so if he changes it to "wontfix", arguing is not recommended. Enhancement requests are welcome (a maintainer has to change the type from 'defect' to 'enhancement'), but please see below about searching, as Steve has already commented on several enhancements he doesn't want to implement.

So, realizing that this is your chance to help make CyanogenMod better by providing the best issue/bug/enhancement report possible, please read carefully.

Contents

[edit] Before you report anything

First, make sure your issue isn't covered on the troubleshooting page. Many of the frequent issues with solutions are listed there.

Second, ask around in #cyanogenmod on irc.freenode.net (or via the cyanogenmod.com web portal here. While the common issues are on the troubleshooting page, some less common (or more recent) issues are known to the regulars there.

Thirdly, make sure your issue isn't already reported:

  • change the search dropdown to 'All Issues'
  • search with as few words as possible
    • try a couple different terms; remember that not all reports/reporters are going to be worded how you think of the problem
    • try with the general category of problem, eg 'bluetooth' or 'BT'

If you find an issue that is the same problem as yours, comment on it instead of opening a new one. Include any information that's different in your case from the original report. Please don't just post "me too" type replies, just star the issue to 'vote' for it and be updated by email of additional comments. If the issue is closed and you're having the same problem, don't open a new one; comment on the existing one and one of the maintainers can re-open the issue.

[edit] Reporting an issue

So you've found an issue that hasn't been reported and nobody in #cyanogenmod can help (or they told you to report the issue). Please fill out the template in the issue tracker fully (don't erase it and start writing freeform): 

Summary:

Be descriptive but terse here; "FC in Music with WMA mp4" is good, "Camera issue" isn't, and "OMG BIG PROBLEMS" is horrible. Remember that this is what other people will see when they search for issues, so make it obvious what the problem is (without putting so much text in that the tracker has to wordwrap). The issue maintainers can change this after the fact and will do so if they believe your summary isn't accurate/descriptive enough. 


What steps will reproduce the problem?
1.
2.

Please be as verbose and precise as possible here. "take a picture" is less helpful than "press camera button, let camera app load, press the button on the screen". The more specific information you give here, the more likely other people can reproduce the problem and possibly provide a solution. 


What do you see?
What did you expect to see?

While this may be a bit silly "I see a force close" "I expected to see a picture", sometimes what people expect to see is not in line with how it is supposed to work. 


Please include the following info from FASTBOOT mode
MODEL?
HBOOT?
RADIO?

Depending on your model, fastboot/spl/bootloader mode can be reached by booting the phone with the camera button, volume down, or 'back' held down. If you don't get it the first try, call+menu+end will reboot, then try holding one of the other buttons. This information isn't always pertinent, but please fill it in anyway. The top line of text describes the hardware model, the second line provides HBOOT info, and the fourth line provides the RADIO version. 


Which version of CyanogenMod?

This should be pretty self explanatory. Note that you should upgrade to the latest version of CyanogenMod before reporting an issue. Many fixes aren't listed in the changelog for given versions. However, if you've experienced an issue for several versions, say so here. 


Did you wipe before flashing?

While not necessary each upgrade/install, wiping ('factory reset' or alt+w from recovery) the user data can solve a lot of issues. However it doesn't solve all issues. To test, make a nandroid backup, wipe, and reinstall CM. You can then test the issue again and restore the nandroid to get your data back. If wiping does solve the problem, then don't report the issue, as the cause is bad data somewhere in the system. Further investigation might lead you to the individual data causing the problem, and you can remove that and keep the rest of your data. RA recovery has many different options for wiping, list any/all that you have done here. 


Have you tried running fix_permissions?

fix_permissions (or 'app uid mismatches' in RA recovery) is a script started by Cyanogen to make sure that the apps and their data are consistent across upgrades. Open terminal emulator, 'su' and type 'fix_permissions' and wait a few minutes. The script is also available in CM recovery, though the one there is outdated slightly. 


Have you tried rebooting?

While this should be obvious, sometimes it isn't. 


Apps2sd / partition type/size?

Do you have apps2sd? If so, what partition type (ext2/3/4), and size of the partition? 


What size/class sD card?

If there's no 2/4/6 number inside a C on your card, It's probably class 2. 


Compcache/swap?

Compcache and swap are discussed elsewhere; if you are using either/both, please state how much. 


Please attach a logcat of the issue.

While this isn't strictly necessary for every issue (it is helpful for most), any reports of 'Force Close' (FC) issues without a logcat will probably be marked as 'Invalid'. There are several ways to get a logcat. You can either paste the relevant area (e.g. 'unhandled exception' and the 10-20 lines after) or you can attach a text file (please name it something more descriptive than 'logcat.txt') at the bottom of the report form. The log that logcat pulls from does not survive reboots, however. For reports of reboot/restarting issues, attach/paste the file(s) at /proc/last_kmsg and/or /data/dontpanic/* 


Please provide any additional information below.

This is your space to include any other information you think might be pertinent. Obviously this form is not completely comprehensive, so tell us here if you're using 3rd party apps for a given task, or what other things you've tried to solve it. While we don't need a list of every 3rd party app on your phone, knowing what apps you have that might have something to do with the issue is a good thing.


Even if you fill this out entirely, aren't duplicating another issue, and have done your best to solve it, it may still be closed without a solution. There are various reasons why:

[edit] Issue Statuses

[edit] Open Issues

  • New = All issues start at 'new'. Most never get past this state for various reasons.
  • Verified = Problem has been replicated by at least 3 reporters or one of the senior users. It still may be an Android issue, and may not necessarily be fixed by CM.
  • Accepted = Problem identified as a CM issue. Most likely only Steve will set this.
  • PatchSupplied = someone has attached a patch for the reported problem/enhancement, but it hasn't been accepted by Cyanogen yet.
  • Started = Work on this issue has begun, or a previously fixed/shouldbefixed issue has been repeated after the fix.
  • ShouldBeFixed = A fix will be in the next release or the fix in the current release is still being tested.

[edit] Closed Issues

  • AndroidIssue = The bug is endemic to Android itself, and won't be fixed in CM. Often Steve fixes Android bugs, but some are more difficult than others.
  • Fixed = Developer made source code changes, no new reports have been made.
  • Invalid = This was not a valid issue report. Anyone following the above instructions shouldn't have to worry about this status.
  • Duplicate = This report duplicates an existing issue.
  • WontFix = We decided to not take action on this issue. Steve will decide that certain bugs are too hard/annoying to fix and/or aren't serious enough to bother with. This status is used on rejected Enhancement requests as well.
  • ItsNotABugItsAFeature = This is how cyanogen intended it.
  • StaleIssue = If you don't keep upgrading and reporting on an issue, it'll probably be marked stale after a few new releases. The maintainers will typically request updates on newer versions a couple times before resorting to this tag.
  • AppIssue = Issues with specific applications that aren't a part of CM will be tagged this, especially if the app maker updates and fixes the problem.
  • UserIssue = Seems to be a one off issue with the users device. Another infrequent tag, but this means Yer Doin It Wrong.
  • HardwareIssue = Suspected hardware issue. Obviously harder to prove and more annoying/expensive to fix. SD card issues get this sometimes.

Note that just because an issue is 'closed' does not mean you cannot comment on it or that the maintainers can't reopen it. Unlike, e.g. xda-dev threads that are 'locked',

[edit] Priorities

All issues start at 'low' priority and can only be changed by the maintainers. Many do not progress past this priority. Only issues that are confirmed by multiple sources and impair some basic functionality of the phone get upgraded, and even then may not be. For the most part Steve prioritizes his own work based on things he can duplicate, things that bug him, or similar. Asking for the priority of an issue to be changed will usually not work. The best way to make it obvious that your issue is important is to have other people comment on it. THIS DOES NOT MEAN THAT YOU SHOULD SPAM THE XDA-DEV THREAD WITH THE ISSUE. Just post the link once, if at all. Anyone having similar issues (and paying attention to the top of this thread) should be able to find your issue by searching, which is another good reason to make sure you're descriptive as possible.

[edit] Starring

This is how you can 'vote' for an issue and automatically receive email updates with new posts. While not strictly followed, the number of 'votes' an issue has does tell the maintainers how widespread a problem is (or how popular an enhancement request is). Note that just because you can get 50 other people to star your issue, it will not necessarily make it a higher priority.

[edit] Final thoughts from PsychoI3oy the BugMonkey

Never take anything on the tracker personally (and please don't post anything that could be taken personally; the maintainers can and do delete posts). If your pet issue isn't solved in a timely fashion, is closed without a solution, or the maintainers comment that they can't duplicate it, don't get bent out of shape. Remember that open source development is not only not-for-profit, it's not-for-pay (other than Cyanogen's beer fund) for most of the maintainers/ops/admins/superusers. We like helping and do this for fun, but nobody owes any user anything. If you have an issue that bugs you or prevents you from using features, just stay on the last version that it worked on. There is no imperative to constantly upgrade to the latest-and-greatest; if 4.2.5 works for you, use it. That being said, please do upgrade and check the status of bugs regularly, even if you don't use the updated version for day-to-day work. Along these lines, posts of "this sucks, I'm going back to 4.2.7.1" or "this sucks, I'm going to Dwang's" will not convince anyone to work harder on your bug, and may get your issue closed. Keep the posts professional and constructive and most importantly informative, and we'll all do what we can to fix the issues.

Retrieved from "http://wiki.cyanogenmod.com/index.php/How_to_use_the_issue_tracker"
Personal tools