Re: linux-next: manual merge of the tracing tree with the parisctree

From: Ingo Molnar
Date: Fri Apr 03 2009 - 10:15:49 EST



* Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:

> Hi Kyle,
>
> On Wed, 1 Apr 2009 13:50:34 -0400 Kyle McMartin <kyle@xxxxxxxxxxx> wrote:
> >
> > What's the optimal way to sort out multiple branches in this
> > tree? Apparently Andrew is cross with me because the rtc-parisc
> > branch didn't get picked up... Should I put a list of branches
> > in my kernel.org public_html or something?
>
> I am not quite sure what you are getting at. If you have multiple
> trees (or branches in a tree), I can merge them separately into
> linux-next - just tell me what they are.

One solution, when there are lots of branches, is what we use in the
-tip tree to auto-integrate the auto-*-next output branches.

It works like this:

For each output auto-*-next tree (there's 19 at the moment) there's
a special file under the tip:tip/.tip/auto-branches/ directory.

Say the auto-tracing-next tree is represented via a list of topic
branches in .tip/auto-branches/auto-tracing-next:

tracing/core
tracing/urgent
tracing/ftrace
tracing/mmiotrace
tracing/sysprof
tracing/nmisafe
tracing/stack-tracer
tracing/fastboot
tracing/markers
tracing/ring-buffer
tracing/pipe
tracing/tracepoints
tracing/core-v2
tracing/fastboot-v2
tracing/core-v3
tracing/function-return-tracer
tracing/branch-tracer

# dont know yet:
# tracing/dump-tracer

tracing/options
tracing/profiling
tracing/power-tracer
tracing/powerpc

# broken right now:
# tracing/hw-branch-tracing

tracing/function-graph-tracer
tracing/blktrace
tracing/graph-tracer
tracing/docs
tracing/kmemtrace
tracing/kmemtrace2
tracing/printk
tracing/doc
tracing/syscalls
tracing/syscalls
tracing/filters
tracing/tasks
tracing/kprobes
tracing/hw-breakpoints
tracing/blktrace-v2
tracing/kmemtrace-v2

When things are quiet and there are no known regressions, i type:

tip-integrate auto-tracing-next

and soon afterwards a new tree comes out. I dont have to do any
manual integration, it's all automated, including the cached
resolution of conflicts. If a new conflict comes up i get a shell
prompt, fix the conflict, commit it and the integration continues.

If i'm happy with the end result i push it out.

As you can see it above, branches can be annotated and commented
out. For example this branch:

# broken right now:
#tracing/hw-branch-tracing

was causing boot crashes so we excluded it from the
auto-tracing-next output and linux-next wont crash due to these
known and under-development problems.

Another branch:

# dont know yet:
# tracing/dump-tracer

Is holding commits i'm not sure we want to push upstream yet, so we
dont push it into linux-next. (linux-next is meant for items that
are intended for the next cycle.)

There's a similar list of topics for the other integration trees:

auto-core-next auto-latest auto-stackprotector-next
auto-cpus4096-next auto-oprofile-next auto-timers-next
auto-fastboot-next auto-perfcounters-next auto-tracing-next
auto-generic-ipi-next auto-rt-next auto-warnings-next
auto-genirq-next auto-safe-poison-pointers-next auto-x86-next
auto-iommu-next auto-sched-next
auto-kmemcheck-next auto-sparseirq-next

Over 100 topic branches are active typically just before the merge
window - they go down to below 10 after the merge window. So there's
a constant ebb and flow in topic activity.

We also have a "tip-integrate-all" script that runs through all the
-next branches and integrates them.

These tools can be found under the -tip:.tip/bin/ directory -
there's currently 68 utility scripts there currently, to solve
various probems all around integration tree maintenance, problems
which are often not solved by the base Git toolset adequately.

Hope this helps,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/