> Tony, Nan Hai, do you have any thoughts on merging this > series into ia64 test? Its really far to big to be managed > as a single unit. I would be much more comfortable if > we could track small incremental changes. Even the diff > between the current and previous version (as below) is quite large. I'm open to suggestions. My current inclination is to abandon the existing kexec/kdump patches that are currently in my test tree[1] and replace them with the latest set of patches. So a re-diff of all that is considered good against 2.6.18 would be ideal for that. Breaking the patch into some smaller pieces would also be good, but I don't think this needs to be taken to extremes (just define a few basic areas and split the patch ... I don't thing it is worth spending days/weeks to split this into a sequence of 37 individually crafted patches, with the kernel being fully functional at every one of the 36 intermediate points). -Tony [1] My test tree is not a guaranteed monotonic increasing sequence of changesets. I've already blown it away once before to clean out all the crufty "Auto-update from upstream" commits that my workflow generates. It's due for another clean-up anyway. - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|