On Mon, Feb 06, 2023 at 11:47:13PM +0100, Miquel Raynal wrote: > Hi Srinivas, > > + Greg > > srinivas.kandagatla@xxxxxxxxxx wrote on Mon, 6 Feb 2023 20:31:46 +0000: > > > Hi Michael/Miquel, > > > > I had to revert Layout patches due to comments from Greg about Making the layouts as built-in rather than modules, he is not ready to merge them as it is. > > Ok this is the second time I see something similar happening: > - maintainer or maintainers group doing the review/apply job and > sending to "upper" maintainer > - upper maintainer refusing for a "questionable" reason at this stage. Only the second time? You've gotten lucky then :) This happens all the time based on experience levels of reviewers and just the very nature of how this whole process works. It's nothing unusual and is good overall for the health of the project. In other words, this is a a feature, not a bug. > I am not saying the review is incorrect or anything. I'm just wondering > whether, for the second time, I am facing a fair situation, either > myself as a contributor or the intermediate maintainer who's being kind > of bypassed. > > What I mean is: the review process has happened. Nothing was hidden, > this series has started leaving on the mailing lists more than two > years ago. The contribution process which has been in place for many > years asks the contributors to send new versions when the review > process leads to comments, which we did. Once the series has been > "accepted" it is expected that this series will be pulled during the > next merge window. If there is something else to fix, there are 6 to 8 > long weeks where contributors' fixes are welcome. Why not letting us the > opportunity to use them? Why, for the second time, I am facing an > extremely urgent situation where I have to cancel all my commitments > just because a random comment has been made on a series which has been > standing still for months? There's no need to cancel anything, there are no deadlines in kernel development and I am not asking for any sort of rush whatsoever. So relax, take a week or two off (or month), and come back with an updated patch series when you are ready. And feel free to cc: me on it if you want my reviews (as I objected to these patches as-is) so that we don't end up in the same situation (where one maintainer accepted something, but the maintainer they sent it to rejected it.) Again, there's no rush, and this is totally normal. > What I would expect instead, is a discussion on the cover letter of the > series where Michael explained why he did no choose to use modules in > the first place. If it appears that for some reason it is best to > enable NVMEM layouts as modules, we will send a timely series on top > of the current one to enable that particular case. Why not rework the existing series to handle this and not require "fixups" at the end of the series? We don't normally create bugs and then fix them up in the same patch set, as you know, so this shouldn't be treated any differently. > > >> NVMEM layouts as modules? > > >> While possible in principle, it doesn't make any sense because the NVMEM > > >> core can't be compiled as a module. The layouts needs to be available at > > >> probe time. (That is also the reason why they get registered with > > >> subsys_initcall().) So if the NVMEM core would be a module, the layouts > > >> could be modules, too. > > I know Michael is busy after the FOSDEM and so am I, so, Greg, would > you accept to take the PR as it is, participate to the discussion and > wait for an update? Kernel development doesn't work on "PR" :) And no, I can't take these, as I don't agree with them, and I totally imagine others will object for the same reason I did (and then they would object to me, as the patches would be in my tree, as I am then responsible for them.) So send an updated version whenever you have the chance. Again, there's no rush, deadline, or anything else here. Code is accepted when it is ready and correct, not anytime earlier. thanks, greg k-h
