Re: linux-next: manual merge of the msm tree with the arm tree

[Russell King]

On Wed, Feb 02, 2011 at 11:43:59AM -0800, Greg KH wrote:
> On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> > On Sun, Jan 30 2011, Stephen Rothwell wrote:
> > 
> > > Hi David,
> > >
> > > Today's linux-next merge of the msm tree got conflicts in
> > > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > > ifdefs") from the msm tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary.
> > 
> > What is the best way to resolve this?  I can't really merge against
> > Russell's tree, since he may need to rebase his tree before the merge
> > window?
> 
> Public trees should never be rebased, so that shouldn't happen.

No.  I refuse to operate in a rigid environment.

My tree is made available on the basis that the 'devel' branch is
constantly remerged (sometimes many times a day) from the individual
topic branches; 'devel' is a convenient branch for sfr to pull into
linux-next, and for others to see what's in the tree.

I am not permitted by people in the community to keep my development
work unpublished.

All the requirements from various different people are incompatible,
so I've chosen a way which satisfies the majority on the ARM community,
which is the community my tree serves.  It does not serve mainline
community interests.

So I do not operate a "commit the patch and its fixed" policy except
for branches which people need to be fixed; they need to discuss their
requirements with me to achieve that.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/