Don’t you worry. Our friend here tried to reply to this message, he did so twice in fact with slightly different wording, but it was full of political rage and tu quoque so I assume he fell victim to the spam filter thanks to you special counter-baiting operation so to speak.
That aside, I did a very superficial search and it seems that the original author had already had a pull being rejected on the grounds it was coming straight from his Baikal credentials. It’s a real pity that an apparently very able engineer is just playing pretend despite knowing full well why is it so that LF migh not want to be associated with Baikal in any way.
Serge Semin
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/[email protected]/
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:
Wow:
Oleksiy Protas
Don’t you worry. Our friend here tried to reply to this message, he did so twice in fact with slightly different wording, but it was full of political rage and tu quoque so I assume he fell victim to the spam filter thanks to you special counter-baiting operation so to speak.
That aside, I did a very superficial search and it seems that the original author had already had a pull being rejected on the grounds it was coming straight from his Baikal credentials. It’s a real pity that an apparently very able engineer is just playing pretend despite knowing full well why is it so that LF migh not want to be associated with Baikal in any way.
Serge Semin