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)
>
