Gerrit is kinda a pain when it comes to searching but I finally played with Gerrit search syntax and came up with a couple of searches
find everything for cm13 merged in the past 30 days
https://review.cyanogenmod.org/#/q/...-project:^.*device.*+-translation+-age:30days
same but for cm14.x
https://review.cyanogenmod.org/#/q/...-project:^.*device.*+-translation+-age:30days
if you have a login for CyanogenMod gerrit you can save these as menu items for quick clicking
when logged into the gerrit instance go to your account's preferences and save menu items for
cm 13.0
#/q/status:merged+branch:cm-13.0+-project:^.*kernel.*+-project:^.*device.*+-translation+-age:30days
for cm14.x
#/q/status:merged+-branch:cm-13.0+-project:^.*kernel.*+-project:^.*device.*+-translation+-age:30days
now let's walk through the search flags used
this could be entered in the search box on review.cyanogenmod.org
status:merged -branch:cm-13.0 -project:^.*kernel.* -project:^.*device.* -translation -age:30days
let's look at our CM-14.x example since it makes the cm13.0 one make sense as well
status:merged to look for a merged commits
everything else had to be exclusions to get to what we want to see. the age: flag only looks for stuff before a certain date and a minus sign excludes so we'd have to use -age:#days/weeks,etc to show stuff in the past # timeframe
-age:30days
Since we're looking at the past 30 days, most commits (as of this writing) are on the Nougat/cm-14.0 branches and a little stuff on the cm-13.0 branch. So with our 30 day window, any merges NOT cm-13.0 branch are probably gonna be cm-14.x branches. If you can see, when cm-15 comes all you need to do is play with this part.
-branch:cm-13.0
I don't care about everyone's devices. I just want to see plain old CyanogenMod commits so I'll exclude the device and kernel projects. I used regular expressions to exclude any projects with either kernel or device somewhere in the project name. the carat symbol ^ enables regular expressions in Gerrit Search and the rest is regex syntax per Gerrit's documentation.
-project:^.*kernel.*
-project:^.*device.*
I also don't want to see any translation updates so I'll just put in a general exclusion on those
-translation.
I just wanted to write something up for myself. Might as well pass it along.
With these bits and pieces I could probably filter it down a little more but this is the guts of what I need to do so.
edit- refined it a little more
status:merged -branch:cm-13.0 -project:^.*kernel.* -project:^.*device.* -project:^.*hardware.* -project:^.*hudson.* -translation -age:30days
Related
Being an "open source Home Replacement app", I spent a couple of hours yesterday trying to find a public repository where I could get ADWLauncher's code.
Looking at its google projects page, it seems that the project is quite active, yet the latest source I could find is under the CyanogenMod github, with ongoing translations but with sources last updated 3 months ago... In AnderWeb's github things are even worse with last commit over a year ago...
Does anyone know of a public repository where i could get the project's latest source code?
Thanks!
Found it !
Hi florpor,
you can find ADW Launcher repository on GitHub.
As I'm a new user, I cannot post you the URL, so here is the info to find it :
on github, look at the "AnderWeb" user projects. It is the one named "android_packages_apps_Launcher".
However, the project seems to be stalled.
Have a nice chekout
I don't think there is any source for the new version. There were many contributors on that project, but it looks like they have all agreed to go proprietary all of a sudden. They haven't announced anything on their project page, so who knows what's going on.
Is this source meant to be compiled for devices other than non AOSP because I got device files and everything and so far its going well.
Droid RAZR XT912
Sent from my XT912 using xda app-developers app
Nvm. I need some file called init
Sent from my XT912 using xda app-developers app
From 11/19:
CM 10.1 Status Update
So we continue to work through the merger of 4.2 code and our CM enhancements. A branch in our github repos called mr1-staging has been created to facilitate the merger and is the target for core CM items (not features).
mr1-staging is not meant to be compile-able, its only purpose is to be a staging grounds for our core work. Chances are, it is useless for independent builders.
CM 10.0 (4.1.2) code is in jellybean-stable, if you are working on a bug-fix for the last stable release, patches should be submitted against that branch. If/when we do another 4.1.2 release (ie CM 10.0.x), it will originate from code in this branch.
Once staging is done in mr1-staging, we will push all that code to a 'CM10.1' branch, and eventually back to our primary 'jellybean' branch. This process is in place to make sure that we effectively move forward from CM 10.0 code, instead of starting over as was seen with the jump from Gingerbread to ICS. Patches from gerrit will be accepted towards CM 10.1, but for now, please have patience while we work through mr1-staging.
While the 4.2 updates are on a smaller scale, they do present some changes that will need to be considered and will effect our implementation of features. Just to name them briefly: Telephony Split, Multi-User, Quick Settings, and Lock-Screen Widgets. These items will be a strong focus when the initial CM10.1 branch is created.
On the feature front, David van Tonder (dvtonder) decided to make his weekend productive, and has already worked on the code for the majority of our MMS enhancements: Emoji support, sms split, gestures and templates, quick messaging. Notably MMS auto retrieve is not being forward ported as Google fixed that themselves. As stated above, patches will hit gerrit review after this staging process is completed.
As always, a timeline isn't and won't be available. We will continue to provide updates as we have them.
Click to expand...
Click to collapse
and 11/21:
Cry havoc and let slip the...
...developers of CM. Hmm, not quite the same oomph to it. Back on topic...
mr1-staging as it's manifested in github right now, is good to build. Theme Engine support is not yet enabled, so if you attempt to build, remove vendor/tmobile. Everything else is in working shape with regards to AOSP devices, so if any of you are waiting for a working tree to move on to har
dware support, you can start now.
A bunch of our repositories have already been merged into mr1. The usual CM externals are in place, the CM build scriptage is also in and working. Features are not incorporated wholesale, and will be applied as conflicts with 4.2 changes are resolved.
Those watching at home, you should be able to break out a Mako (unofficial) build at this time. Our frequent contributors have been given the green light to send patches for review as features are rebased, recoded, and uploaded.
*Nightlies will not be available immediately, as even though CM may be build-able we consider it incomplete at its current stage. When we are happy with the product, the flood gates will open.*
Happy Dev'ing and say thanks to your patient lady/man for putting up with you
Click to expand...
Click to collapse
AOSPA PARANOID ANDROID GOES OPEN SOURCE ON GIT
To all developers and maintainers out there,
we took our time to get a stable hands-free build-box ready, sorry you had to wait for so long but we had alot of work to do and we did not want to release something that is half-baked.
AOSPA is a new project for us, as you know, we started by basing on Cyanogenmod. This one is based 100% on AOSP. AOSPA is meant to be a stock oriented, lean ROM that delivers essential ROM-scene tweaks while retaining the elegance and ease of the original. We do not invest much time kanging other ROMs or teams, our primary focus is and will remain invention.
WHAT TO DO
As a developer you will need a couple of links to get up to speed.
If you just want to build, you find our Github here: http://github.com/paranoidandroid/
Kick it off by executing: repo init -u [email protected]aranoidAndroid/manifest.git-b jellybean
The only way to build PA is by using . rom-build.sh [devicename]
Hands off 'make' please. If everything works as expected it should ask for and fetch vendor files automatically.
If you would like to participate and help us, our Gerrit is here: http://review.paranoid-rom.com/
Legacy devices must supply their own trees and blobs. We do not accept any compromises to AOSP, please keep hacks out of it and overlay them properly.
Maintainers can freely take this project and release where ever they want. If you use our name, please make sure you stay true to our vision. Do not clutter this ROM with everything-everyone-ever-asked-for.
If you like to base your project on PA, no problem. Just treat the base with respect.
Kangers can take whatever they want, blow yourselves out.
NEW POLICIES REGARDING PA-PREFS
We unstamped the app and it may be used in any ROM. We do this under one condition. Do not mix it with DPI nonsense, ever! Do not merge it with AOKP's DPI changer, Dual-Panel Stuff, anything "true-tablet" related. If you do that we will pull it out of your project.
We do not wish to be the target of Googles retribution, and they take app-breaking VERY serious and could end any ROM if they wanted. Hybrid engine is safe as milk and will not break one single app in the entire Play market. But if you get our source wrong or mix it with conflicting code, you will - using our name and reputation. Please treat it respectful and give your users a decent experience!
Click to expand...
Click to collapse
Links:
https://plus.google.com/107979589566958860409/posts
https://github.com/paranoidandroid/
https://play.google.com/store/apps/details?id=com.paranoid.preferences.pro
http://www.paranoid-rom.com/forum/g...ut-how-to-compile-paranoidandroid-from-sauces
This should be fun to play with
私のEVO 3Dから送信される。
I've had a few interactions lately about git and how to make more advanced use of it for development pn Android. I thought it would be worth sharing some good links:
git users manual
- Canonical reference for git
a tutorial introduction to git
- A simple set of steps that has you create a small git repository and play with it. Highly recommended to try.
Everyday git
- Takes the tutorial idea a bit further by essentially watching a kernel maintainer's screen. Good to skim over to see basic thought processes.
Branching and merging with git
- A very thorough article about branches and merging. Recommended, but is long.
gitref.org
- An exploration of the various commands git uses with fantastic examples and summaries
The tutorial is good to get you started, the "Everyday git" is good to start to learn how to use some of the power of git. The branching and merging is really important, but hard, to really understand some of the great power of git.
One piece of git that I think is particularly important for anyone that wants to send pull requests to public repos or maintain repos that other people will use is the "rebase" function of git. Here's a good example of using it in a standard development work-flow:
git rebase example
Before pushing commits, it's generally nice to look at them objectively and to ask yourself: would someone that didn't participate in the development of these commits read the list and make sense of them? Ideally, the one line subjects (git log --online --no-merges) should make a clear progression of commits, grouped by function/module/topic and with clear descriptions and subjects.
It is said elsewhere in the links, but I'll say it too. Don't rebase commits that you have pulled from the git server. You should not rewrite published history, only the history that you have created locally and are ready to push upstream.
Hi all,
Is there a specific way to hunt down commits for feature sets in the source of ROMs on github? As a simple example, let's say someone was searching my ROM for how to enable AppOps in AOSP. They would eventually find this commit:
https://github.com/nowsci/platform_...mmit/a766afc88ebed960c2027d3d1539ff9a38be4115
However, many feature additions require changes across many repositories for Android. Let's say I want to find the Expanded Volume Control code for Cyanogenmod. The only way I can think to do this is to clone every single Cyanogenmod repository, print out the git log, and comb through for every mention of "volume" until I find the right commits.
How do other ROM developers shortcut this?
I ask for my own education, and because I think a central repository of "features" that links all the commits and provides the merge commands for AOSP might be a handy thing to start creating in the community (unless there is already a better way).
Thanks!