On Wed, 12 Jun 2024 16:09:40 +0200 "Jason A. Donenfeld" <Jason@xxxxxxxxx> wrote: > > > > I think "Depends-on" is the way to go, as it is *not* a stable thing, and > > what is in stable rules is only about stable patches. > > How does "Depends-on" not spiral out of control? There's a *lot* of > "Depends-on" relations one could express in commit series and such. Of > course a lot of git itself is designed to show some subset of these > relationships. If a change occurs because a recent change happened that allows the current change to work, then I think a Depends-on is appropriate. Like in this example. I thought this change was broken, and it would have been except for a recent change. Having the dependency listed is useful, especially if the dependency is subtle (doesn't break the build and may not show the bug immediately). > > It seems like in most cases, the "Cc: stable@v.g.o # x.y.z+" notation > expresses the backporting safety correctly. What is the purpose of > saying, "if you need this patch for any reason, you also need patch X"? > Who is the intended audience, and are you sure they need this? The intended audience is someone backporting features and not fixes. > > I ask these questions because I wind up doing a lot of work backporting > patches to stable and marking things properly for that or submitting > manually backported stable patches and so forth, and in general, patch > applicability for stable things is something I wind up devoting a lot of > time to. If I have to *additionally* start caring about the theoretical > possibility that somebody in the future, outside of the stable flow, > might not understand the context of a given patch and blindly apply it > to some random tree here or there, that sounds like a lot of extra brain > cycles to consider. > > So, is this actually necessary, and how does it not spiral out of > control? How would you see it going out of control? And "Depends-on" would only be used for non stable relationships. If stable backports, we can keep with the current method. -- Steve
