Hi, On Sat, 5 Apr 2025 at 03:46, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > * Sean Christopherson <seanjc@xxxxxxxxxx> [250404 17:48]: > > On Fri, Apr 04, 2025, David Hildenbrand wrote: > > > On 04.04.25 20:05, Liam R. Howlett wrote: > > > > But then again, maybe are are not going through linux-mm for upstream? > > > > > > [replying to some bits] > > > > > > As all patches and this subject is "KVM:" I would assume this goes through > > > the kvm tree once ready. > > > > Yeah, that's a safe assumption. > > Okay, thanks. > > It still seems strange to have such vast differences in the cover letter > between versions and require others to hunt down the information vs an > updated cover letter with revision history and links. > > I did get lost on where the changes since v6 stopped vs new comments > started in the update. > > But maybe it's that I'm set in my grumpy old ways. > > I really like the cover letter information in the first patch (this > patch 1 of 7..) to have the information in the git log. > > > > > > > It looks like a small team across companies are collaborating on this, > > > > and that's awesome. I think you need to change how you are doing things > > > > and let the rest of us in on the code earlier. > > > > > > I think the approach taken to share the different pieces early makes sense, > > > it just has to be clearer what the dependencies are and what is actually the > > > first thing that should go in so people can focus review on that. > > > > 100% agreed that sharing early makes sense, but I also 100% agree with Liam that > > having multiple series flying around with multiple dependencies makes them all > > unreviewable. I simply don't have the bandwidth to track down who's doing what > > and where. > > Yes, sharing early is crucial, but we lack the quilt file to stitch them > together in the proper sequence so we can do a proper review. > > My main issue is barrier of entry, I have no idea how I can help this > effort as it is today. > > > > > I don't see those two sides as conflicting. Someone "just" needs to take point > > on collecting, squashing, and posting the various inter-related works as a single > > cohesive series. > > It *looks* like all these patches need to go in now (no RFC tags, for > instance), but when you start reading through the cover letters it has > many levels and the effort quickly grows; which branch do I need, what > order, and which of these landed? This is like SMR, but with code. > > > > > As you said, things are getting there, but I recommend prioritizing that above > > the actual code, otherwise reviewers are going to continue ignoring the individual > > series. > > > > FWIW, if necessary, I would much prefer a single massive series over a bunch of > > smaller series all pointing at each other, at least for the initial review. > > > > Yes, at least then the dependency order and versions would not be such > an effort to get correct. If it's really big maybe a git repo would be > a good idea along with the large patch set? You'd probably be using > that repo to combine/squash and generate the patches anyways. I still > don't know what patch I need to start with and which ones have landed. > > If each part is worth doing on its own, then send one at a time and wait > for them to land. This might result in wasted time on a plan that needs > to be changed for upstreaming, so I think the big patch bomb/git branch > is the way to go. > > Both of these methods will provide better end-to-end testing and code > review than the individual parts being sent out in short succession with > references to each other. The idea was that it would be easier to review the two series separately, with the second one being tagged as RFC (which I accidentally dropped). That ended up making this more confusing and difficult to review. The next series will just be one series. Thanks for your feedback and sorry for the noise. Cheers, /fuad > Thanks, > Liam
