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? Or is it best to just have you carry the conflict resolution in
linux-next, and I make the resolution during the next merge window?
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
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.
thanks,
greg k-h
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:
On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> 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.
merging is fine, right?
Not rebasing, you really don't want to do that. Linus has been all over
that topic in the past, I doubt he wants to bring it up again in detail.
> 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 the goal of the ARM community isn't for the mainline community? That
sounds like a big problem.
> 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.
I'm not telling you how to run your branches, other than the simple fact
of: "if it's public, it shouldn't be rebased". See Linus's comments for
why this is.
thanks,
greg k-h
On Wed, Feb 02, 2011 at 12:32:52PM -0800, Greg KH wrote:
> On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> > 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.
>
> merging is fine, right?
>
> Not rebasing, you really don't want to do that. Linus has been all over
> that topic in the past, I doubt he wants to bring it up again in detail.
>
> > 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 the goal of the ARM community isn't for the mainline community? That
> sounds like a big problem.
>
> > 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.
>
> I'm not telling you how to run your branches, other than the simple fact
> of: "if it's public, it shouldn't be rebased". See Linus's comments for
> why this is.
I'm not going to get involved in an argument over this. If people
insist on telling me not to publish then I'll do exactly that - I'll
make my tree hidden from public view.
My personal preference was not to publish, but my hand was forced.
I've added Nicolas so he can fight for having my tree visible in an
unstable form.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Wed, 2 Feb 2011, Russell King wrote:
> On Wed, Feb 02, 2011 at 12:32:52PM -0800, Greg KH wrote:
> > On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> > > 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.
> >
> > merging is fine, right?
> >
> > Not rebasing, you really don't want to do that. Linus has been all over
> > that topic in the past, I doubt he wants to bring it up again in detail.
Linus has said that you are not supposed to rebase other people's tree.
The obvious reason is that once you rebase someone else's work, you void
all the testing that person might have done since the environment is not
the same as the one in which it was tested initially. This came about
because davem (just to name a prominent figure) did use to rebase other
people's tree he pulled into his tree in order to make a nice linearized
history for some reasons.
Linus also said that, if you do publish a tree for others to base their
work on, you must not rebase your tree for obvious reasons.
But never did Linus say that rebasing was outright forbidden. There are
cases where it is appropriate (e.g. linux-next) and other cases where it
is not. For people without enough git fu to make the difference then it
is best not to rebase. but in some workflows it is just the right
thing to do.
> > > 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 the goal of the ARM community isn't for the mainline community? That
> > sounds like a big problem.
Please stop spreading B/S.
> > > 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.
> >
> > I'm not telling you how to run your branches, other than the simple fact
> > of: "if it's public, it shouldn't be rebased". See Linus's comments for
> > why this is.
Then for all purposes please just consider RMK's tree as non existent.
That should solve your problem.
Those who've worked well with RMK and his semi-rebasing workflow for the
last 5 years should continue to do so as they see fit.
If you do need a stable branch for some features you need to base your
work on, then just ask RMK for one. He always managed it in the past.
The actual problem here is that some people, notably the msm folks, are
bypassing the maintainer hierarchy and going straight to Linus for their
pull requests instead of asking RMK to pull. We once debated this at
some point and it was agreed that completely independent SOC specific
code with no dependencies on the common ARM code _could_ go straight to
Linus directly if they crave for it. But in this case:
1) the conflict is obviously simple
2) the conflict resolution is just as obvious
3) and Stephen is able and willing to carry this conflict resolution for
the foreseeable future until this all gets merged in mainline.
So... WTF is the actual problem here?
Nicolas
On Wed, Feb 02 2011, Nicolas Pitre wrote:
> The actual problem here is that some people, notably the msm folks, are
> bypassing the maintainer hierarchy and going straight to Linus for their
> pull requests instead of asking RMK to pull. We once debated this at
> some point and it was agreed that completely independent SOC specific
> code with no dependencies on the common ARM code _could_ go straight to
> Linus directly if they crave for it. But in this case:
>
> 1) the conflict is obviously simple
>
> 2) the conflict resolution is just as obvious
>
> 3) and Stephen is able and willing to carry this conflict resolution for
> the foreseeable future until this all gets merged in mainline.
>
> So... WTF is the actual problem here?
I hadn't really brought this up as a problem, but was mostly wondering
if it was ok to just have Stephen carry the conflict resolution until
the next merge window. The rest of the comments came from Greg.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Wed, Feb 02 2011, Nicolas Pitre wrote:
> The actual problem here is that some people, notably the msm folks, are
> bypassing the maintainer hierarchy and going straight to Linus for their
> pull requests instead of asking RMK to pull. We once debated this at
> some point and it was agreed that completely independent SOC specific
> code with no dependencies on the common ARM code _could_ go straight to
> Linus directly if they crave for it.
I also have no real problem sending pull requests to RMK instead of
Linus, as long as it isn't a pain. Linus gives clear directions as to
how his tree works, and when he expects what kinds of pull requests.
Weird web-based patch tracking systems are a pain. Pull requests from
git with a fairly easy way to know when they've been pulled are not.
I also find that http://ftp.arm.linux.org.uk/ is frequently
inaccessable, and usually slow.
As it stands, so far, it's been a lot less work for me to send directly
to Linus, and resolve the issues that come up when they do.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Wed, 2 Feb 2011, David Brown wrote:
> On Wed, Feb 02 2011, Nicolas Pitre wrote:
>
> > The actual problem here is that some people, notably the msm folks, are
> > bypassing the maintainer hierarchy and going straight to Linus for their
> > pull requests instead of asking RMK to pull. We once debated this at
> > some point and it was agreed that completely independent SOC specific
> > code with no dependencies on the common ARM code _could_ go straight to
> > Linus directly if they crave for it.
>
> I also have no real problem sending pull requests to RMK instead of
> Linus, as long as it isn't a pain. Linus gives clear directions as to
> how his tree works, and when he expects what kinds of pull requests.
> Weird web-based patch tracking systems are a pain. Pull requests from
> git with a fairly easy way to know when they've been pulled are not.
RMK accepts pull requests. He also stated pretty clearly when he wishes
for those requests to happen, or rather when it is too late for those
requests to come by so he has a chance to sort his tree out in time for
the merge window.
> I also find that http://ftp.arm.linux.org.uk/ is frequently
> inaccessable, and usually slow.
The "slow" part should be fixed now that the Git server over there has
been configured to serve Git requests using the Git smart protocol over
HTTP.
Admitedly, if RMK had a public mirror on git.kernel.org that would help
things (a lot of people do have rebasing Git repos there already).
> As it stands, so far, it's been a lot less work for me to send directly
> to Linus, and resolve the issues that come up when they do.
This is however more work for Linus who already expressed some concerns
about too many people going to him directly while he'd prefer a more
distributed flow.
Nicolas
On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote:
> The actual problem here is that some people, notably the msm folks,
> are
> bypassing the maintainer hierarchy and going straight to Linus for
> their
> pull requests instead of asking RMK to pull. We once debated this at
I don't think it's fair to single out MSM here. Going straight to Linus
was discussed at one point, as I recall, and Russell didn't oppose it at
the time. There are a number of ARM sub-architecture maintainers that do
this.. None of that is related to the rejects created here, those would
happen no matter who we submitted pull requests to.
I think the issue is more that MSM is actively being cleanup , and
Russell is touching code that we're working on also. So we need a way to
work together .. In this case the collision is so simple that either
Linus or Russell would just fix it up while pulling, and both would
likely be fine with that. In the past I've tried to fix up these issues,
but now I think maybe it's doesn't matter.
In terms of Russell rebasing, I don't really like that. I've based MSM
trees on Russell's stable branch and it's worked in the past. If
Russell's rebasing then we can't really do that, so one tool to fix
these problems is gone.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
On Fri, Feb 04, 2011 at 09:17:34AM -0800, Daniel Walker wrote:
> On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote:
> > The actual problem here is that some people, notably the msm folks,
> > are
> > bypassing the maintainer hierarchy and going straight to Linus for
> > their
> > pull requests instead of asking RMK to pull. We once debated this at
>
> I don't think it's fair to single out MSM here. Going straight to Linus
> was discussed at one point, as I recall, and Russell didn't oppose it at
> the time. There are a number of ARM sub-architecture maintainers that do
> this.. None of that is related to the rejects created here, those would
> happen no matter who we submitted pull requests to.
>
> I think the issue is more that MSM is actively being cleanup , and
> Russell is touching code that we're working on also. So we need a way to
> work together .. In this case the collision is so simple that either
> Linus or Russell would just fix it up while pulling, and both would
> likely be fine with that. In the past I've tried to fix up these issues,
> but now I think maybe it's doesn't matter.
>
> In terms of Russell rebasing, I don't really like that. I've based MSM
> trees on Russell's stable branch and it's worked in the past. If
> Russell's rebasing then we can't really do that, so one tool to fix
> these problems is gone.
The alternative is that I don't publish patches in git form. Or do I
publish patches in git form and never add any acks or tested-by
information to them ever.
It's really no skin off my nose if I never add any acks, tested-by or
reviewed-by tags to my patches - it actually means _less_ work for me.
I'd prefer to give credit where credit is due, but if idiotic rules
mean that I can't, that's really not my problem.
Goody, I can spend that time doing more productive work.
So, here's a questionaire:
1. Would it be acceptable to keep the p2v changes hidden from public view
via git for months, and only available in patch form as I'm waiting for
acks from people?
2. Would you have found this if these changes weren't in linux-next?
3. Would you have found it by applying my patches from the mailing list to
your tree?
4. Is it acceptable not to acknowledge people who've tested and reviewed?
The answers are most probably: no, no, no and no.
And now you see my dilema: 1 is incompatible with 4.
I argue that you're better off _seeing_ the changes via git and linux-next
because then linux-next can pick up these conflicts when they happen and
we can sort out the resulting mess when that happens.
I've no problem _eventually_ freezing the p2v branch, but the p2v stuff is
currently in flux: althrough I've requested acks from Nicolas, none are
forthcoming yet - and there's going to be some further work:
| > Thanks, merged those in. Can I have new acks for the p2v branch please?
|
| Yes, hopefully soon. I should also restore Thumb2
| support in the process.
So you tell me - do I take the p2v stuff out of public view tonight
because it's not stable, and therefore you don't even know about the
conflict?
Or do I continue publishing the unstable changes so that people have
the ability to see what's going on in my tree and find potential
conflicts?
I really don't care which - but I'll warn you that keeping changes
hidden will result in a reduction of patch quality, and much much
much less testing of those changes. And I won't care at all when you
complain that MSM's broken because of one of my patches.
Exactly what would you prefer?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Fri, Feb 04 2011, Russell King wrote:
> I really don't care which - but I'll warn you that keeping changes
> hidden will result in a reduction of patch quality, and much much
> much less testing of those changes. And I won't care at all when you
> complain that MSM's broken because of one of my patches.
>
> Exactly what would you prefer?
I'd like to get a little bit of an idea what you would prefer me to do.
I see two reasonable workflows:
- I make a branch for the files that conflict with other changes in
the ARM tree and submit pull requests to you (Russell) for these
changes. Other MSM-specific changes would be in another tree that
goes to Linus.
- I submit everything via pull requests to you. This would probably
result in one additional request to you, that contained the stuff
that didn't conflict, since it would be nice to resolve the obvious
conflicts earlier.
The later is more work for you, and less for Linus.
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Fri, 2011-02-04 at 17:42 +0000, Russell King wrote:
> So you tell me - do I take the p2v stuff out of public view tonight
> because it's not stable, and therefore you don't even know about the
> conflict?
>
> Or do I continue publishing the unstable changes so that people have
> the ability to see what's going on in my tree and find potential
> conflicts?
>
> I really don't care which - but I'll warn you that keeping changes
> hidden will result in a reduction of patch quality, and much much
> much less testing of those changes. And I won't care at all when you
> complain that MSM's broken because of one of my patches.
>
> Exactly what would you prefer?
I'm not really opposed to any of your objectives. What it sounds like is
that you have a "stable" branch, and an "unstable" branch. Both branches
are in linux-next , and we're seeing conflicts from the unstable one. Is
that accurate?
I think we can deal with the issues as long as you have one branch that
you don't rebase, and things eventually move into that branch. So if we
have a conflict then we can base our tree on your stable branch , and
have confidence that your not rebasing it, or merge that into our tree.
I think the problem is that when you say your rebase it's not clear if
your rebasing all your branches, or if you only rebasing one unstable
branch..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
On Fri, 4 Feb 2011, Daniel Walker wrote:
> On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote:
> > The actual problem here is that some people, notably the msm folks,
> > are
> > bypassing the maintainer hierarchy and going straight to Linus for
> > their
> > pull requests instead of asking RMK to pull. We once debated this at
>
> I don't think it's fair to single out MSM here. Going straight to Linus
> was discussed at one point, as I recall, and Russell didn't oppose it at
> the time. There are a number of ARM sub-architecture maintainers that do
> this..
The point still stands for msm as well as for the others. And this is
now causing fuss amongst second guessers as this thread is showing.
But this aside, this is still putting more load on Linus while this load
could be more distributed.
> None of that is related to the rejects created here, those would
> happen no matter who we submitted pull requests to.
Indeed. And trivial is the fix, which is what I've said too.
> I think the issue is more that MSM is actively being cleanup , and
> Russell is touching code that we're working on also. So we need a way to
> work together .. In this case the collision is so simple that either
> Linus or Russell would just fix it up while pulling, and both would
> likely be fine with that.
Exact.
Maybe this would be nicer to Russell and others performing wide ranging
changes to the ARM code if the msm tree was more visible downstream, and
potentially help to avoid making a mountain out of a mole hill.
> In the past I've tried to fix up these issues,
> but now I think maybe it's doesn't matter.
I'm sure Stephen knows about git's rerere facility, or he might have
developed one of his own by now, hence his proposal to carry simple
conflict resolution for as long as required. So yes, I don't think this
is something that must be "fixed" if carrying the fix in the downstream
tree causes more trouble than the trivial merge involved.
> In terms of Russell rebasing, I don't really like that. I've based MSM
> trees on Russell's stable branch and it's worked in the past. If
> Russell's rebasing then we can't really do that, so one tool to fix
> these problems is gone.
Russell has so named his "stable" branch for a reason. I'll let you
guess what it is. :-)
Nicolas
On Fri, Feb 04 2011, Nicolas Pitre wrote:
> Maybe this would be nicer to Russell and others performing wide ranging
> changes to the ARM code if the msm tree was more visible downstream, and
> potentially help to avoid making a mountain out of a mole hill.
Currently, the msm tree is in linux-next, and the URL is in the
MAINTAINER's file. The only want to make it more visible would be to
give frequent pull requests to RMK, which would create extra work for
him. I think I just need to come up with the right balance of how often
to give the tree to RMK.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.