linux-kernel - Re: [PATCH v7 07/15] scsi: fnic: Add and integrate support for FDMI

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b3c29afc-c49b-42af-9733-7cf2b934cd90@stanley.mountain>
Date: Tue, 14 Jan 2025 12:59:33 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: John Meneghini <jmeneghi@...hat.com>
Cc: Karan Tilak Kumar <kartilak@...co.com>, sebaddel@...co.com,
	arulponn@...co.com, djhawar@...co.com, gcboffa@...co.com,
	mkai2@...co.com, satishkh@...co.com, aeasi@...co.com,
	jejb@...ux.ibm.com, martin.petersen@...cle.com,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v7 07/15] scsi: fnic: Add and integrate support for FDMI

On Mon, Jan 13, 2025 at 12:35:03PM -0500, John Meneghini wrote:
> Just a note to say that these patches are important to Red Hat and we
> are actively engaged in back porting and testing these patches in to
> RHEL-9 and RHEL-10.
> 
> I think these issues that Dan has pointed out are all issues which
> can be addressed in a follow up patch.

I mean we already merged this.  I only got involved because of static
checker issues in linux-next.

What I'm complaining about is not so much any specific issue but just
that the process was not followed.  Normally this patch would not
be merged.  If anyone sent a patch like this to drivers/staging it
would have triggered Greg's patch-bot automated response:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

This rule is the same in every subsystem.  No one wants to merge a patch
like this.  But what happened is the patch sat on the list and only
Hannes and Martin were doing any review.  Karan was left doing all the
work with no help or guidance.  Eventually Martin has to give up right?
The patchset isn't up to normal standards but it's basically okay and
Martin can't do every single thing by himself and eventually it's pretty
clear no one else is coming to help.  It is what it is etc.

Please understand this in the gentlest way.  Next time if something is
important then assign an engineer to help out.  It would have taken a day
to prepare this patchset for merging.  You had seven months.  It's not
fair to show up five days before the merge window asking for special
exemptions from the review process.  Maintainers and reviewers are
already overworked, they shouldn't have to work around your deadlines.

>From what I've seen Karan is absolutely doing a good job addressing the
problems I reported so it's fine.  But normally this is not how it works.

regards,
dan carpenter