On Mon, Aug 03, 2009 at 04:27:40PM -0400, Valerie Aurora wrote: > I'm curious what you think of this proposal: Redo all the foo() -> > foo2() patches in the entire 64-bit series as a semantic patches. Well, certainly assembling all of the 64-bit changes into a single patch is a good thing; I'm currently doing it by hand, by rearranging patches and transplanting patch hunks around. The reason why I hesitate about automating things is that when then have to follow up the patch with one that fixes up the types of various variables, and also printf format statements, etc. In addition, one challenge that has to be taken into account is that once we start making wholesale changes, we start breaking the rest of the patches in the patch queue. So there are probably some changes that we probably want to do by hand, and merge them into the tree first. This includes the bitmap changes (which I've simplified to the point where we don't need make the *_bitmap -> *_bitmap64 type changes any more), the filesystem swap code (which I think has an ABI change and I want to fix slightly differently), the 64-bit dblist code (which I want to look at more closely) and the progress meter code (which again I want to clean up their API first). So we probably need to merge some patches by hand before we get to the changes that can be done via spatch. Otherwise, if we start making redoing thesemantic patch changes right away, the concern is that we'll miss some of the more subtle changes that are contained within the patch series. If you want to start preparing for the semantic patches by preparing and testing the receipes, and then helping to flag those patches that contain some changes that contain some changes that can't be applied via spatch, that would be helpful. Does that sound like a plan? -Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
