Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: Status of arm-soc.git for 3.2 | Date | Fri, 6 Jan 2012 23:36:30 +0000 |
| |
On Wednesday 04 January 2012, Russell King - ARM Linux wrote: > On Tue, Jan 03, 2012 at 10:43:06PM +0000, Arnd Bergmann wrote: > > The merge window is almost there, so it's time to look at what we've queued > > up in the arm-soc tree. There is a total of 55 branches with 386 non-merge > > changesets on top of mainline and the dependencies (linux-arm, v4l and > > dmaengine). The total diffstat is: > > > > 676 files changed, 19694 insertions(+), 12633 deletions(-) > > Well, my tree looks like this: > 937 files changed, 8150 insertions(+), 10774 deletions(-) > > > I would like to stop adding non-bugfix patches into the branches above now > > for 3.2, and instead merge everything that I receive from now on into > > late/* branches, so we don't destabilize the patches that are already there > > and so I can feel more comfortable about sending everything in the next/* > > branches upstream ASAP. > > I think that's a must - for both our trees. We have quite a number of > conflicts in linux-next between our trees and other trees - some of them > due to duplicated commits being applied.
Hmm, I'll have to check that, I was hoping that we manged to weed out the duplicated commits. Do you have a list, or some (semi-)automated way to find those, or are those just random commits you stumbled over.
> I'm feeling less than confident about my tree for this upcoming merge > window than I've ever felt before - I think we're in for quite a bit > of stick, possibly from Linus, over the about of silly conflicts and > duplicates which we have with other trees.
Yes, the silly conflicts last time were a bit too much. Linus always says that he wants to see the conflicts when they happen, but we really shouldn't let him see conflicts between your tree and arm-soc. I think we can eliminate those at least by pulling in your branches where the conflicts happen.
Olof has updated the arm-soc tree to the latest version of your devel-stable branch, which means that all conflicts between that and the branches in arm-soc should be dealt with already. I've added one merge from devel-stable into our next/drivers2 branch to prevent a modify/rename conflict and resolved silly conflicts between branches within arm-soc.
> It's proven to be _impossible_ to sanely do an architecture wide change > to the way the restart stuff is handled - because SoC maintainers have > taken to adding their own individual patches for it to their git trees. > What I had hoped was to get that all sorted by the end of November, and > publish the whole thing as a stable branch, but that was utterly thwarted > by non-responsive maintainers - for example, some of this stuff only > getting finally fixed _yesterday_.
I've not resolved the conflicts between stuff in arm-soc and your restart branch yet, because I don't know in what order we should do the merges.
We can certainly submit 'arm-soc/fixes-non-critical', 'arm-soc/cleanups' and 'rmk/devel-stable' right away because there are no conflicts between those. That alone would get us a great deal forward.
The rest of the arm-soc branches more or less depend on your 'devel-stable' and conflict with your 'restart' branch. If you want to go first, you can submit your that branch now, and Olof or I will resolve the conflicts with it before pushing the arm-soc branches. Alternatively, we submit everything except 'next/move' and 'next/drivers2' (those should come last) once your 'devel-stable' is in and let you work out the conflicts. I'm fine with it either way, but as you say it's certainly not a easy ride to get them all resolved.
> To some extent, it still is being thwarted by non-responsive maintainers: > the "Temporary #error" commit is still there. I'm in two minds about > whether to push that up to Linus or not - they've had sufficient warning > both on this mailing list, by personal email, and a #error being in > linux-next making their platform(s) unbuildable for about a month. > > Therefore, I have no issues what so ever breaking the three platforms > (gemini, shmobile, vt8500) which remain unconverted at the next merge > window, and I don't care what they say about that happening. (If they > cared, they should respond to email.)
Yep, agreed.
> However, one thing that really concerns me is that we're going to have > to go through all this again over the next three months, because of the > arch_idle changes which Nicolas has. I am not looking forward to that.
If you prefer, I can try to handle those in arm-soc, but I'm not sure if that helps. We can try.
Arnd
| |