lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7be870fc2b2fa01b89708208c78cc041029252aa.camel@redhat.com>
Date: Thu, 24 Oct 2024 09:32:46 +0200
From: Philipp Stanner <pstanner@...hat.com>
To: Serge Semin <fancer.lancer@...il.com>, Jon Mason <jdmason@...zu.us>, 
 Dave Jiang <dave.jiang@...el.com>, Allen Hubbe <allenbh@...il.com>,
 ntb@...ts.linux.dev, Andy Shevchenko <andy@...nel.org>, Andy Shevchenko
 <andriy.shevchenko@...ux.intel.com>, Kory Maincent
 <kory.maincent@...tlin.com>, Cai Huoqing <cai.huoqing@...ux.dev>, 
 dmaengine@...r.kernel.org, Mark Brown <broonie@...nel.org>, 
 linux-spi@...r.kernel.org, Damien Le Moal <dlemoal@...nel.org>, 
 linux-ide@...r.kernel.org, Paul Burton <paulburton@...nel.org>, Thomas
 Bogendoerfer <tsbogend@...ha.franken.de>, Arnd Bergmann <arnd@...db.de>,
 Jiaxun Yang <jiaxun.yang@...goat.com>,  linux-mips@...r.kernel.org, Bjorn
 Helgaas <bhelgaas@...gle.com>, Manivannan Sadhasivam
 <manivannan.sadhasivam@...aro.org>, Yoshihiro Shimoda
 <yoshihiro.shimoda.uh@...esas.com>,  linux-pci@...r.kernel.org, "David S.
 Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>, Russell King
 <linux@...linux.org.uk>, Vladimir Oltean <olteanv@...il.com>, Keguang Zhang
 <keguang.zhang@...il.com>, Yanteng Si <siyanteng@...ngson.cn>, 
 netdev@...r.kernel.org, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk@...nel.org>, Guenter Roeck <linux@...ck-us.net>, 
 linux-hwmon@...r.kernel.org, Borislav Petkov <bp@...en8.de>, 
 linux-edac@...r.kernel.org, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>,  linux-serial@...r.kernel.org
Cc: Andrew Halaney <ajhalaney@...il.com>, Nikita Travkin <nikita@...n.ru>, 
 Ivan Kokshaysky <ink@...assic.park.msu.ru>, Alexander Shiyan
 <shc_work@...l.ru>, Dmitry Kozlov <xeb@...l.ru>,  Sergey Shtylyov
 <s.shtylyov@....ru>, Evgeniy Dushistov <dushistov@...l.ru>, Geert
 Uytterhoeven <geert@...ux-m68k.org>, Sergio Paracuellos
 <sergio.paracuellos@...il.com>,  Nikita Shubin <nikita.shubin@...uefel.me>,
 linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux: Goodbye from a Linux community volunteer

On Thu, 2024-10-24 at 07:27 +0300, Serge Semin 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.

I'm also quite shocked and even baffled about how this has been
handled. This is not how leaders should communicate difficult or big
decisions. It's the most disappointing event I have witnessed in the
project.

There is the form and there is the content – about the content one
cannot do much, when the state he or his organization resides in gives
an order.

But about the form one can indeed do much. No "Thank you!", no "I hope
we can work together again once the world has become sane(r)"... srsly,
what the hell.

No idea why they felt the need to do it that way, but it certainly is
not the open source way, neither is it decent or honorable.


That said, thank you for all your work, Serge!

I believe that nothing that has been accomplished with a candid mindset
and decent intentions is ever done for nothing, although it often pays
off way differently than expected.
So I hope this will be the case for you, too.

Take care,
Philipp


> 
> 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@gmail.com/
> 
> 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)
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ