OpenPDroid cherry-pick

[mateor]

I am going to create a cherry-pickable commits for these patches, I think. The fact that the build patches work for all roms implies to me that this is doable.

That way we can offer several different methods of applying OpenPDroid- build patches, easy cherry-picks, or smali-patches.

I also think that perhaps we could rethink the need for holding so many device trees. But I know you are considering offering manifests. But I think that aosp-jb-mrx branches with squashed release commits would be fine.

As a last note, I am writing a small script that will apply the patches with a single command. It will just apply and remove, spooling to a log so it can find, record, and back out of failed hunks. It should be done this week, not too hard to make, just need to find the time.

[wsot]

I don't actually know what you mean by 'cherry-pickable commits': unless you mean generating git diffs so that they can then be applied directly to a repository?

My only concern about offering so many different ways of applying OpenPDroid patches is that people may get confused about what they actually need to do.

When you say 'we could rethink the need for holding so many device trees' you mean the various rom-specific branches in the repositories? I have mixed feelings about removing them, because right now it means that I can merge in specific changes to each ROM and correct any specific issues that may occur. Normally they don't occur, and I basically just make changes on the jb-mr1-release-openpdroid-devel branch then cherry-pick that to all the others, but sometimes conflicts do occur and need tidying.

I'm also not sure what you mean by "But I think that aosp-jb-mrx branches with squashed release commits would be fine." I think you're steeped in more scene lingo than me...

As for the patching script: cool, sounds useful.

[mateor]

Well, we are offering patches that work for all rom trees. So why carry source for all trees? I think that any problems that may occur between rom types can be resolved as we move from devel branches to release.

We have the patches now, and I think a patch script will relieve some of the obnoxiousness of the current instruction set (when it was three repos, that was okay, but with five+ we are pushing it).

But the cherry-pick process is familiar to anyone who builds roms and is already part of their skill set. Many people (developers or home builders) will never apply a patch to their roms- that is what the commits are for.

I am not wedded to removing the branches, especially if it is a part of your work process to use them. But I think that having five commits to cherry-pick in is worth considering. Basically what would be done is that I would apply the patches, immediately before release and after checking the to-be-released patches against the popular device trees (cm, aokp, etc.) to a clean aosp tree. Then commit that all at once. That commit would be our release commit.

That way, if they added our repos as a remote, they could commit and revert the OpenPDroid framework SUPER easily, and with a process they already know and use, in less steps and a safer way. Ask the thread what they think maybe. I understand the less is more, but cherry-picked commits tend to be how Android framework changes are distributed.

[mateor]

Closing. I think what I offer at github.com/mateor/patchScripts is my best solution.