On Mon, Feb 01, 2021 at 10:31:33PM +0530, Dwaipayan Ray wrote:

On Mon, Feb 1, 2021 at 10:07 PM Greg KH [off-list ref] wrote:

quoted

On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:

quoted

Hi,
on linux-next,
$ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
gives:
4a2d78822fdf
12ca45fea91c
09f2724a786f

These are patches from the year 2085, 2037 and 2030 respectively.

Would a checkpatch rule be helpful for these or are they too
isolated to waste runtime on?

Dates come from your email client, not the patch itself, how is
checkpatch going to catch this?

I was hoping that the maintainer could catch it before merging it
into his tree. Dates being a trivial thing might slip human eyes,
but checkpatch might detect it there.

What is the problem here.  You can't treat dates that patches were
"created", you have to always go off of the release the patches showed
up in.  So while you might want to do a sliding scale of 4 months or so,
in reality we have patches committed to the tree today that were written
years ago.

I think I still hold the record for "time it took to get a patch merged"
with a very old devfs removal patch, which was many many years...

thanks,

greg k-h
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees