While Google+ has become our go-to outlet for day to day status updates, we realize that not all of you are active users and don’t always see the latest news and information posted there. In an effort to work around that shortfall, we will be posting weekly roundups every Friday, starting today. As this is the first in the series and it is already mid-June, this post will encompass the last few weeks.

Road 10.1.0

We continue to move through iterations as we approach the official 10.1.0 release. Users who used RC3 may experience a disproportionately high rates of reported data usage. This was a bug that was resolved for RC4, and the bad values calculated by RC3 were only cosmetic, so rest assured that you did not use 100GB worth of data in 24h. RC5 was put out late last week, and has been holding up pretty solidly. There are a handful of identified bugs that we are working on, and we have not yet decided if a RC6 is needed; we’ll let you know if that occurs.

New Devices

We have begun nightly builds for most major Qualcomm variants of the Galaxy S4 line up. This includes the GSM, CDMA and i9505 models. At this point, these devices are not slated to be included in the ongoing Release Candidates.

Technical Infrastructure

The wiki, forum, and this blog have all been transferred to new servers. You should see performance increases, especially with respect to the wiki. We will be continuing this upswing in activity, with a homepage redesign in the coming weeks. If you notice any odd behaviors, please let us know in the comments.

Incognito for Apps

On Wednesday, Cyanogen took to G+ to give a sneak peak at what he has been working on this past week. Tentatively titled “Run in Incognito Mode” he is developing a process to allow you a simple and easy privacy tool. While not as granular as the permission revoking of CM7, this new functionality should grant you peace of mind when apps request your contacts, calendar, messages, location or browser history. This will be enabled on a per-app basis. For more information, read Cyanogen’s post here. There will be more in this space as this functionality develops.

Got a suggestion for a topic you’d like to see in the next round-up? Let us know in the comments below. All device/port requests will be ignored.

We haven’t used the ‘Release Candidate’ nomenclature since the ICS days, but we feel the 10.1 branch is quickly approaching the point where a ‘final’ build is due. To prepare for that eventuality, RC1 builds for CyanogenMod 10.1.0 are now landing on our servers! This will be one of (if not the last) milestone releases before a 10.1.0 is pushed out. These builds will appear as they complete the build process and, as always, you can download the builds via get.cm!

The RC1 release list is as follows (codenames):

• a700
• captivatemtd
• crespo
• crespo4g
• d2att
• d2cri
• d2mtr
• d2spr
• d2tmo
• d2vzw
• e975
• endeavoru
• epicmtd
• galaxysmtd
• grouper
• hercules
• i9100g
• maguro
• mako
• manta
• odroidu2
• otter
• otter2
• p3100
• p3110
• p5100
• p5110
• p760
• p880
• p930
• quincyatt
• quincytmo
• skyrocket
• steelhead
• su640
• tf700t
• tilapia
• toro
• toroplus
• vs920

A little more than a month removed from our last M-release, the 10.1-M2 releases are now landing on our servers. These builds are based on Android 4.2.2.

We’ve expanded the release list to include quite a few new devices since the M1; the full list is further below.

With this release, we’d like to remind you all that while bug reports on nightlies will get summarily dismissed, we accept and encourage reports to be submitted against the M2 release. By identifying issues in the M-release, you can help to make the eventual ‘stable’ release that much better. Note that our bug tracker has relocated to jira.cyanogenmod.org. Additionally, if you report a bug but fail to attach a log (logcat or adb bugreport), your report will be considered invalid, and closed. Even if your device bursts into flames: no attached log means it didn’t happen.

Devices receiving an M release today are as follows:
Acer Iconia a700
Google Nexus S (crespo, crespo4g)
Google Nexus 7 (grouper, tilapia)
Google Galaxy Nexus (toro, toroplus, maguro)
Google Nexus 4 (mako)
Google Nexus 10 (manta)
Google Nexus Q (steelhead)
Hardkernel Odroid-U2
HTC One X (evita)
HTC Incredible 4G LTE (fireball)
HTC Evo 4G LTE (jewel)
HTC One S (ville)
LG Nitro HD (p930)
LG Optimus LTE (su640)
LG Spectrum (vs920)
Samsung Galaxy S (captivatemtd, galaxysbmtd, galaxysmtd, epicmtd)
Samsung Galaxy SII (i9100g, hercules, skyrocket)
Samsung Galaxy SIII (US variants d2att, d2cri, d2mtr, d2spr, d2tmo, d2vzw)
Samsung Note (quincytmo, quincyatt)
Samsung Galaxy Tab 2 7.0 (p3100, p3110)
Samsung Galaxy Tab 2 10.1 (p5100, p5110)

As per usual, the code has been tagged in our Github as ‘cm-10.1-M2’. Any device currently receiving 10.1 nightlies, but not listed above, will continue to get worked on until they are ready. This includes the Kindle Fire, Galaxy R and Motorola Devices added yesterday.

Happy Flashing,
The CyanogenMod Team

CyanogenMod has been due for a new issue tracker for a while now.

The existing Google Code tracker was started when we only supported 2 devices and Cyanogen was the only developer. Now we have about 150 devices and almost as many developers/maintainers, across 3 major versions of Android. There are almost 500 open issues on the tracker and nearing 7000 submitted in the last 3 years. The logcats and screenshots (and the occasional mp3 or video) attached to all the issues take over a gigabyte of space, and each increase in that quota has to be asked for manually. Google recently silently removed the RSS feed for all project updates, making issue tracking a bit harder for me.

The last two points there indicate the need for our own hosted solution. As several project members have worked with it before, JIRA was chosen. They provide a free licence for open-source projects (just like Google Code) and provide for a much better bug submission form and overall workflow.

If you have ever submitted a bug to a bugzilla or trac issue tracker, JIRA should be easily useable. Instead of the Google Code single-textarea form that is easily blanked, there are text boxes for each piece of required data with descriptions below. The bug searching should be better than Google Code’s, and the need for me to hand-tag every issue will be reduced (if not largely eliminated). In addition, we have loaded a plugin that ties our issue tracker to gerrit, better tracking when bugs are solved.

Utkanos, our wonderful new Wiki overlord, has rewritten my (admittedly bad) “How to use the issue tracker” page both for clarity and to correspond to JIRA.

But, and this is a big ‘but’, there are no pre-existing ways to transfer Google Code issues en-masse to JIRA. JIRA supports importing from several other trackers, as well as CSV files, but not Google Code. Meanwhile, Google Code doesn’t have any easy export options (the CSV download offered on the main issue list is only the summary/tags, not the complete text and comments) and the Google Data (gdata) XML interface can pull either the initial submitted report for all issues or comments for one. I haven’t found any good xml-to-csv converters that can handle the data, and writing one by hand has proved problematic at best.

So we will need you, the community, to re-submit your bugs to JIRA. For me to manually copy/paste everything by hand would be hours, if not days, of work. For each one of you that has submitted a bug or enhancement request to move your report to JIRA should only take a few moments.

This blog post will coincide with a bulk update of all open issues (except ‘shouldbefixed’ ones already handled). I would request that only the original submitter copy their issue into the new tracker. When doing so, they should include a link back to the original googlecode submission so I can close it. Alternatively, a link on googlecode to the new JIRA bug will suffice.

As of right now, new issues will NOT be accepted on the Google Code tracker, users should begin submitting bug reports to the JIRA instance at jira.cyanogenmod.org. Existing issues will be closed as they are moved to JIRA. In a couple weeks, I will close any remaining issues on the Google Code tracker. After that point, anything reported on JIRA will be treated as a new issue, and the google code tracker will be closed and shut down.

[An added bonus to the move to Jira is the ability for you as end users to better communicate what you’d like to see included in CyanogenMod. A new form and tag for ‘feature request’ has been added. As with bug submissions, you should search to see if your request or one similar to it has already been submitted. Duplicates, or perceived duplicates, will be merged. Please understand, unlike bugs (where we shipped something in a broken state) we are under no such obligation to fulfill requests. The sheer number of you out there compared to those available to code instantly eliminates our ability to fulfill every request. That said, if we spot a good idea that also interests us (and that’s the key stipulation here), we will work towards it.]

This has and will be a lot of work for everyone, but ultimately we will have complete control of our bug tracker and hopefully a better experience for users and developers going forward.

-PsychoI3oy, your CyanogenMod BugMonkey

With CM10 we started doing “M-Series” builds every month. These builds are intended to be mostly stable and ready for everyday use. We suspended building these after the initial release in order to focus on 10.1, which is now on track to a stable release. Today we are doing our first M build for 10.1, based on Jelly Bean MR1. More devices are being worked on, and are available as nightly builds for the time being.

We’re building M for these devices:
* Samsung Captivate
* Samsung Nexus S (+4G)
* Samsung Galaxy S3 USA models (D2*)
* Samsung Galaxy S (galaxysmtd/galaxysbmtd)
* Google Nexus 7
* Google Galaxy Nexus (all variants)
* Google Nexus 4
* Google Nexus 10
* ODroid U2
* Samsung P3100, P3110
* Samsung P5100, P5110

Head over to Get.CM to find a build for your device.

Enjoy our first release of CM-10.1 and please report any and all bugs you find to our bug tracker.

(ciwrl wrote this, I’m just posting on his behalf so this is resolved)

So earlier today we put up a post on what prompted us to transition to our new CyanogenMod.org domain. We refrained from identifying the ex-member out of respect for his privacy and career outside of CM. Suffice it to say you guys aren’t slouches, and figured it out on your own.

With that said, the ex-member in question contacted us and has agreed to hand over control of the CyanogenMod.com domain. This was done as amicably as these things can be, and CM did not pay the fee he requested.

We will still be using CyanogenMod.org as our primary domain, and the .com address will simply redirect to this new domain. Ironically enough, ‘.org’ is better than ‘.com’ as we are not a commercial entity, and is far more in line with how CyanogenMod is structured.

We received a common question, that we’d like to take a moment to answer. Some of you contacted us mentioning that you had previously donated to a different address. When the forum began, up until about 3 months ago, the forum utilized this other address as the mechanism for forum donations and establishment of the ‘Donator’ badge. Donations made to this address prior to three months ago were used for the CyanogenMod forum IPB licence and forum related costs and were not misappropriated.

On a side note, we have also gone through internal restructuring to make sure that this sort of thing doesn’t happen again. Nobody has control over everything, and there is no longer such a large single-point of failure. Our lessons have been learned.

We ask that you please not perform any vigilante actions, we do not condone any such thing; just let this fade.

We want to move on, get you the builds you expect from us, and not mess around with distractions.