On Monday 18 October 2010 22:12:54 Daniel Walker wrote: > On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote: > > > > Ok, well in that case why not accept this immediately after the merge > > > window? A point when everything is quiet, and most of the tree's are > > > empty? > > > > RMK has his own merge window which closes about at the same time as > > Linus' one opens. We thought this was happening last week and therefore > > this change was supposed to be the last one. > > It seems like that could potentially make these kinds of problem worse, > since your merging things immediately before sending them to Linus. Like > right now we only have a fairly short amount of time to correct this > conflict. What Nicolas was talking about is the *end* of the merge window, not the start. This is how all sensible maintainer trees work: you get to merge stuff into the maintainer tree for a number of weeks (some start at -rc1, other start a bit later). When Linus tells people to get ready for the release, the subsystem goes into regression fix mode and when Linus opens his merge window, everything should be reasonably stable. > > > Well how about I merge this change into my tree ? > > > > If you ask RMK to merge your tree in his that would be much simpler to > > add this change in a single pass afterwards. > > I can do that , but would I still be able to merge stuff into my tree? > Seems like I could, Russell would just clean up the conflict and my tree > would just move forward like it has been already , and I would send the > whole thing to Linus. When you know that Russell does not rebase his tree, you can pull his tree into yours whenever a change hits his tree that impacts you in a major way. You shouldn't do this too frequently, but it's a good way to resolve conflicts like this one. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
