* Nikita Kalyazin <kalya...@amazon.com> [250407 10:05]: > ...
> > > > All of this is extremely confusing because the onus of figuring out what > > the final code will look like is put on the reviewer. As it is, we have > > issues with people not doing enough review of the code (due to limited > > time). One way to get reviews is to make the barrier of entry as low as > > possible. > > > > I spent Friday going down a rabbit hole of patches referring to each > > other as dependencies and I gave up. It looks like I mistook one set of > > patches as required vs them requiring the same in-flight ones as your > > patches. > > > > I am struggling to see how we can adequately support all of you given > > the way the patches are sent out in batches with dependencies - it is > > just too time consuming to sort out. > > I'm happy to do whatever I can to make the review easier. I suppose the > extreme case is to wait for the dependencies to get accepted, effectively > serialising submissions, but that slows the process down significantly. For > example, I received very good feedback on v1 and v2 of this series and was > able to address it instead of waiting for the dependency. Would including > the required patches directly in the series help? My only concern is in > that case the same patch will be submitted multiple times (as a part of > every depending series), but if it's better, I'll be doing that instead. Don't resend patches that someone else is upstreaming, that'll cause other problems. Three methods come to mind: 1. As you stated, wait for the dependencies to land. This is will mean what you are working against is well tested and won't change (and you won't have to re-spin due to an unstable base). 2. Combine them into a bigger patch set. I can then pull one patch set and look at the parts of interest to the mm side. 3. Provide a git repo with the necessary changes together. I think 2 and 3 together should be used for the guest_memfd patches. Someone needs to be managing these to send upstream. See the discussion in another patch set on guest_memfd here [1]. As this is not based on fully upstream patches, this should be marked as RFC, imo. Thanks, Liam [1]. https://lore.kernel.org/all/aizia2elwspxcmfrjote5h7k5wdw2stp42slytkl5visrjvzwi@jj3lwuudiyjk/
