Christian Schoenebeck wrote on Fri, Dec 09, 2022 at 03:40:06PM +0100: > > > You remember updating the 1st patch as well, right? :) > > > > It looks up to date to me, e.g. zc is added at the end of the p9_fcall > > structure. > > (and these are the only two patches you sent, right? :D) > > Mmm, that's the queued patch I see: > https://github.com/martinetd/linux/commit/298468c26c14682a5be80a6ec1b4880c8eb3b261 > > Which is v1 ('zc' is not at the end of the structure, and in v1 there were > multiple assignment in the same line like: > > req->tc.zc = req->rc.zc = false; > > which caused code style checker to bark (as well as on the commit log which it > found too short). So in v2 it is: > > req->tc.zc = false; > req->rc.zc = false; > > And yes, only two patches. :) Ah. . . what did I just say about applying patches in my local branch for testing later, they correct one is just sitting there but wasn't tested/pushed yet :/ (if you care, I'm using my 9p-test branch for that, but it's not sent sent to -next obviously) > Well, workflows are quite different. Personally I always manually reply to > mailed patches once I queued them, so that people can verify and correct me in > case I queued the wrong ones. I never had the feeling to script that part. Yes I usually do write a note about it when I take the patch locally, but in this case I think I just applied the patches for checkpatch (indentation looked off without being sure it'd complain) and didn't intend to queue it; then came back later and "oh they're here, thanks past me!" (incorrectly) I guess at this point the problem comes back down to not running tests/pushing to next immediately; if I finish automating that part I think this kind of errors wouldn't happen as non-pushed patches wouldn't make sense... Well, it's been rare enough but still worth thinking about safeguards imo, there's usually a reason for v2 patchs so getting the v1 in even occasionally is bad :-D -- Dominique
