Hello Serge! I do not have many contributions to show to give it extra weight nor do I actually know you. Nevertheless I still wanted to say thank you for your nice message even if it is for a sad occasion, and share your sentiment of hoping for more pleasant circumstances. Best regards, Reimar (and apologies if anyone is annoyed by the wide CC list, but I think it's important for at least some thank yous to be public and nobody else seems to have written one yet) > On 24 Oct 2024, at 06:27, Serge Semin <fancer.lancer@xxxxxxxxx> wrote: > > Hello Linux-kernel community, > > I am sure you have already heard the news caused by the recent Greg' commit > 6e90b675cf942e ("MAINTAINERS: Remove some entries due to various compliance > requirements."). As you may have noticed the change concerned some of the > Ru-related developers removal from the list of the official kernel maintainers, > including me. > > The community members rightly noted that the _quite_ short commit log contained > very vague terms with no explicit change justification. No matter how hard I > tried to get more details about the reason, alas the senior maintainer I was > discussing the matter with haven't given an explanation to what compliance > requirements that was. I won't cite the exact emails text since it was a private > messaging, but the key words are "sanctions", "sorry", "nothing I can do", "talk > to your (company) lawyer"... I can't say for all the guys affected by the > change, but my work for the community has been purely _volunteer_ for more than > a year now (and less than half of it had been payable before that). For that > reason I have no any (company) lawyer to talk to, and honestly after the way the > patch has been merged in I don't really want to now. Silently, behind everyone's > back, _bypassing_ the standard patch-review process, with no affected > developers/subsystem notified - it's indeed the worse way to do what has been > done. No gratitude, no credits to the developers for all these years of the > devoted work for the community. No matter the reason of the situation but > haven't we deserved more than that? Adding to the GREDITS file at least, no?.. > > I can't believe the kernel senior maintainers didn't consider that the patch > wouldn't go unnoticed, and the situation might get out of control with > unpredictable results for the community, if not straight away then in the middle > or long term perspective. I am sure there have been plenty ways to solve the > problem less harmfully, but they decided to take the easiest path. Alas what's > done is done. A bifurcation point slightly initiated a year ago has just been > fully implemented. The reason of the situation is obviously in the political > ground which in this case surely shatters a basement the community has been built > on in the first place. If so then God knows what might be next (who else might > be sanctioned...), but the implemented move clearly sends a bad signal to the > Linux community new comers, to the already working volunteers and hobbyists like > me. > > Thus even if it was still possible for me to send patches or perform some > reviews, after what has been done my motivation to do that as a volunteer has > simply vanished. (I might be doing a commercial upstreaming in future though). > But before saying goodbye I'd like to express my gratitude to all the community > members I have been lucky to work with during all these years. Specifically: > > NTB-folks, Jon, Dave, Allen. NTB was my starting point in the kernel upstream > work. Thanks for the initial advices and despite of very-very-very tough reviews > with several complete patchset refactorings, I learned a lot back then. That > experience helped me afterwards. Thanks a lot for that. BTW since then I've got > several thank-you letters for the IDT NTB and IDT EEPROM drivers. If not for you > it wouldn't have been possible. > > Andy, it's hard to remember who else would have given me more on my Linux kernel > journey as you have. We first met in the I2C subsystem review of my DW I2C > driver patches. Afterwards we've got to be frequently meeting here and there - > GPIO, SPI, TTY, DMA, NET, etc, clean/fixes/features patch(set)s. Quite heat > discussions in your first reviews drove me crazy really. But all the time we > managed to come up with some consensus somehow. And you never quit the > discussions calmly explaining your point over and over. You never refused to > provide more detailed justification to your requests/comments even though you > didn't have to. Thanks to that I learned how to be patient to reviewers > and reviewees. And of course thank you for the Linux-kernel knowledges and all > the tips and tricks you shared. > > * Andy, please note due to the situation I am not going to work on my DW DMAC > fixes patchset anymore. So if you ever wish to have DW UART stably working with the > DW DMA-engine driver, then feel free to pick the series up: > Link: https://lore.kernel.org/dmaengine/20240911184710.4207-1-fancer.lancer@xxxxxxxxx/ > > Linus (Walleij), after you merged one of my pretty much heavy patchset in you > suggested to me to continue the DW APB GPIO driver maintaining. It was a first > time I was asked to maintain a not-my driver. Thank you for the trust. I'll > never forget that. > > Mark, thank you very much for entrusting the DW APB SSI driver maintenance to > me. I've put a lot of efforts into making it more generic and less errors-prune, > especially when it comes working under a DMA-engine control or working in the > mem-ops mode. I am sure the results have been beneficial to a lot of DW > SPI-controller users since then. > > Damien, our first and last meeting was at my generic AHCI-platform and DW AHCI > SATA driver patches review. You didn't make it a quick and easy path. But still > all the reviews comments were purely on the technical basis, and the patches > were eventually merged in. Thank you for your time and experience I've got from > the reviews. > > Paul, Thomas, Arnd, Jiaxun, we met several times in the mailing list during my > MIPS P5600 patches and just generic MIPS patches review. It was always a > pleasure to discuss the matters with such brilliant experts in the field. Alas > I've spent too much time working on the patches for another subsystems and > failed to submit all the MIPS-related bits. Sorry I didn't keep my promise, but > as you can see the circumstances have suddenly drawn its own deadline. > > Bjorn, Mani, we were working quite a lot with you in the framework of the DW > PCIe RC drivers. You reviewed my patches. I helped you to review another patches > for some time. Despite of some arguing it was always a pleasure to work with > you. Mani, special thanks for the cooperative DW eDMA driver maintenance. I > think we were doing a great work together. > > Paolo, Jakub, David, Andrew, Vladimir, Russell. The network subsystem and > particularly the STMMAC driver (no doubt the driver sucks) have turned to be a > kind of obstacle on which my current Linux-kernel activity has stopped. I really > hope that at least in some way my help with the incoming STMMAC and DW XPCS > patches reviews lightened up your maintainance duty. I know Russell might > disagree, but I honestly think that all our discussions were useful after all, > at least for me. I also think we did a great work working together with Russell > on the DW GMAC/QoS ETH PCS patches. Hopefully you'll find a time to finish it up > after all. > > Rob, Krzysztof, from your reviews I've learned a lot about the most hardwary part > of the kernel - DT sources and DT-bindings. All your comments have been laconic > and straight to the point. That made reviews quick and easy. Thank you very > much for that. > > Guenter, special thanks for reviewing and accepting my patches to the hwmon and > watchdog subsystems. It was pleasure to be working with you. > > Borislav, we disagreed and argued a lot. So my DW uMCTL2 DDRC EDAC patches even > got stuck in limbo for quite a long time. Anyway thank you for the time > you spent reviewing my patches and trying to explain your point. > > * Borislav, it looks like I won't be able to work on my Synopsys EDAC patchsets > anymore. If you or somebody else could pick them up and finish up the work it > would be great (you can find it in the lore archive). The patches convert the > mainly Zynq(MP)-specific Synopsys EDAC driver to supporting the generic DW > uMCTL2 DDRC. It would be very beneficial for each platform based on that > controller. > > Greg, we met several times in the mailing lists. You reviewed my patches sent > for the USB and TTY subsystems, and all the time the process was straight, > highly professional, and simpler than in the most of my other case. > Thank you very much for that. > > Yoshihiro, Keguang, Yanteng, Kory, Cai and everybody I was lucky to meet in the > kernel mailing lists, but forgot to mention here. Thank you for the time spent > for our cooperative work on making the Linux kernel better. It was a pleasure to > meet you here. > > I also wish to say huge thanks to the community members trying to > defend the kicked off maintainers and for support you expressed in > these days. It means a lot. > > A little bit statics of my kernel-work at the end: > > Signed-off patches: 518 > Reviewed and Acked patches: 253 > Tested patches: 80 > > You might say not the greatest achievement for seven years comparing to some > other developers. Perhaps. But I meant each of these tags, be sure. > > I guess that's it. If you ever need some info or consultation regarding the > drivers I used to maintain or the respective hardware or the Synopsys IP-cores > (about which I've got quite comprehensive knowledge by this time), feel free to > reach me out via this email. I am always willing to help to the community > members. > > Hope we'll meet someday in more pleasant circumstances and drink a > couple or more beers together. But now it's time to say good bye. > Sorry for a long-read text. I wish good luck on your Linux-way. > > Best Regards, > -Serge(y) >