On Wed, Nov 14, 2012 at 10:06:49AM +0000, Viresh Kumar wrote:
> On 14 November 2012 15:23, Liviu Dudau <liviu.du...@arm.com> wrote:
> > On Wed, Nov 14, 2012 at 06:33:29AM +0000, Viresh Kumar wrote:
> > Hi Viresh,
>
> Hi Liviu,
>
> >> There are two categories of branches/patches that are kept here. One that
> >> are
> >> guaranteed to work on current big LITTLE system (Tested on ARM Vexpress
> >> TC2)
> >
> > How is that guarantee created? Do you have a set of tests that you are
> > going to run
> > before declaring it working? Interested to have a bit more detail here.
>
> It was a Weakly ordered statement :)
>
> Actually, the most important patchset present in this tree for now is
> "task placement"
> from Morten. Which enabled big LITTLE behavior. We can add any patch to master
> which doesn't break this branch.
>
> Earlier i got Vincent's and Preeti's patches, which broke this and so
> we have to come
> with this solution.
>
> Yes, i do test these branches with MP Demo i created some time back.
> Also, we are
> planning to do some sysbench/cyclic tests on both merge branches.
Good, cheers!
>
> >> For now I have created to merge branches:
> >> - big-LITTLE-MP-master-v12: git merge arm-multi_pmu_v2 hw-bkp-v7.1-debug-v1
> >> per-task-load-average-v3-merged task-placement-v2
> >> task-migration-sysfs-tuning
> >> misc-patches config-fragments
> >> - big-LITTLE-MP-exp-v12: git merge intel-powerclamp-driver-v1
> >> per-entity-load-tracking-with-core-sched-v1 sched-pack-small-tasks-v1
> >> sched-timer-wq-migration-v2-resend
> >
> > Not exactly clear what is the transition process from experimental to
> > master.
>
> Whatever doesn't break HMP patches can go into master directly. The purpose
> here is, that partners should be able to test HMP stuff on their boards with
> Linaro kernel.
So the expectations is that partners (ARM included) take the patches from
experimental
and test them with master. Is the onus on the creator of the patch to do the
testing?
>
> > And another question: is there going to be an implicit order in pulling
> > patches
> > in your master branch? (i.e. you pull first the old patches that are known
> > to
> > work because they were previously in -master- before pulling patches from
> > -experimental- ? )
>
> Not sure if i got your question well. Whatever lands into master has very less
> chance to get out to exp. I normally create an octopus merge in my
> merge branches,
> so there is no specific order i follow during these merges.
Question was: when you do the octopus merge, do you place the list of topic
branches
in a specific order or you randomly (or alphabetically) sort the list.
Interested from
a "tracking your git tree" point of view.
Regards,
Liviu
>
> Sorry if i haven't answered it well :(
>
> --
> viresh
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
