On Mon, Feb 11, 2008 at 11:06:17PM -0800, Arjan van de Ven wrote: > There is maybe a middle ground in this -next idea; as very first > part of the series, the new api gets added, current users converted > and api marked __deprecated. > > Then there's a second part to the patch, which is a separate tree, > which gets added at the very end, which removed the old api. > > Both will go in at the same merge window, and the next-meister needs > to track that no new users show up... but the final tree allows this > to be done somewhat more gentle. > > Doesn't work for API changes that just change the API rather than > extending it, and doesn't solve the dependency issues. So I still > think a cleansweep works best in general, but I suspect Andrew just > disagrees with that. Yes, that's exactly what I was suggesting. The __deprecate only lasts for the merge window, and we remove the old API at the end of the merge window. So it's only there for a very short time, and it's only there to make the cleen sweep a little less painful --- not one where "shit hangs around in the tree forever". - Ted - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html