05.12.2012 08:32, Viresh Kumar пишет:
On 5 December 2012 09:55, John Stultz john.stultz@linaro.org wrote:
So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like).
That might be enough, i suppose.
Are you saying that cpufreq-interactive-gov would not be needed in this case? Thus excluding the case when someone wants the interactive governor, but without the rest of the android code. (I thought it was one of the reasons to have a separate cpufreq-interactive-gov topic vs more frequent updates to the existing android topic)
However, if you're maintaining your own tree anyway, why not have Andrey pull your tree in addition to the current linaro-android-3.x-*rebase branch?
Since they are both contain a common subset, the merge will likely be quite easy.
Not quite right. At least the android topic is the rebase, so these topics are quite different from git's perspective. I've tried merging Viresh's topic into llct containing the Anton's version of the android topic. There were 2 conflicting files. One file was 3 commits ahead of the llct, and it would be much more easier to cherry pick those commits into llct than trying to associate the combined diff with the 3 commits. As for the 2nd file, it was just one additional commit in the Viresh's branch, but it wasn't the topmost commit in that branch for some reason. That is such merge needs some manual work, and I don't feel comfortable doing such merges w/o good knowledge of android or the governor at least. Also there may be conflict resolutions or fixes done when creating or updating the android topic, and they can be omitted by occasion when merging cpufreq-interactive-gov-master into llct.
The things would be pretty trivial, if cpufreq-interactive-gov-master were based on the android topic. But cpufreq-interactive-gov-master is intended to be used without the android topic as well, right? This means outside the linux-linaro kernel trees btw.
That way Andrey's tree will have a better chance of having the latest changes.
Does that seem ok?
That was the initial idea, but there were concerns from Tixy and Andrey on that. @Andrey: Do you want to comment again?
imho the conflicts when merging cpufreq-interactive-gov-master into llct require interactive governor tests in the CI loop. Especially if we want cpufreq-interactive-gov-master to be updated frequently.
How difficult would it be to maintain a special version of the cpufreq-interactive-gov topic for llct: cpufreq-interactive-gov-master rebased onto the most recent android topic? E.g. cpufreq-interactive-gov-linux-linaro?
Thanks, Andrey