public inbox for linux-kernel-mentees@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: "Ignacio Peña" <ignacio.pena87@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [ANNOUNCE] kernel-patch-validator - Tool to validate patches before submission
Date: Thu, 17 Jul 2025 12:29:36 -0400	[thread overview]
Message-ID: <20250717162936.23035-1-ignacio.pena87@gmail.com> (raw)
In-Reply-To: <ZppSfKGao4PQvRJd@kroah.com>

On Thu, Jul 17, 2025 at 08:15:00AM -0400, Greg KH wrote:
> Note, it is now 2025, so this check keeps failing :)

Haha, you caught me! The irony of a date validation tool having its own
date bug... I've already fixed it to properly check against the current
year instead of hardcoding 2025.

> Overall, I like the idea, the implementation needs a bit of work, see
> the few github issues I opened on it for details found in my testing.

Thank you so much for taking the time to test it and open those issues!
I really appreciate the detailed feedback. I've been working through them
this morning:

- Fixed the 2025 check (now validates against current date) 
- Fixed the `set -e` issue so it shows all errors instead of bailing out
- Updated stable email validation to accept both formats
- Removed all the emojis (they looked unprofessional anyway)

> Can you add some of these checks to checkpatch.pl itself?  That would be
> the best thing to do in the end.  Having to use different tools makes
> things harder to keep in sync and to remember to use at all.

You're absolutely right about this. Having separate tools is definitely
not ideal - I often forgot to run my own validator!

I'm thinking the best approach would be:

1. Port the most useful checks to checkpatch.pl (like the changelog 
   placement check that would have saved me from your bot's rejection!)
2. Keep the workflow helpers separate (find-bugs.sh, test-patch.sh) 
   since they do more than just validation

Would you prefer if I start with small individual patches to checkpatch.pl
for each check, or should I put together an RFC first to discuss which
checks would be most valuable to integrate?

I built this tool mainly to understand what I was doing wrong. Now that
I've learned from my mistakes (thanks to you and Dan's feedback), it
makes total sense to help others by putting these checks where everyone
will actually use them.

Thanks,
Ignacio

       reply	other threads:[~2025-07-17 16:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ZppSfKGao4PQvRJd@kroah.com>
2025-07-17 16:29 ` Ignacio Peña [this message]
2025-07-17 16:34   ` [ANNOUNCE] kernel-patch-validator - Tool to validate patches before submission Greg KH
2025-07-17  7:54 Ignacio Peña
2025-07-17 12:15 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250717162936.23035-1-ignacio.pena87@gmail.com \
    --to=ignacio.pena87@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox