fix issues in NOTICE

[pjfanning]

This is a release blocker. If you are in Incubating project, that needs be mentioned in your NOTICE.

Here's an example of Fory's NOTICE.
https://github.com/apache/fory/blob/main/NOTICE

I'm not going to create equivalent PRs in all your other Git repos but someone in the PPMC should update their NOTICE files too.
https://incubator.apache.org/clutch/resilientdb.html

[pjfanning]

@cjcchen the year is still wrong - it is 2025

[pjfanning]

@cjcchen could you update the NOTICE on all of your git repos? You'll find them listed in https://incubator.apache.org/clutch/resilientdb.html

[cjcchen]

@cjcchen could you update the NOTICE on all of your git repos? You'll find them listed in https://incubator.apache.org/clutch/resilientdb.html

Hi PJ,
Yes. I have updated all.

Thanks a lot.

[pjfanning]

@cjcchen could you update the NOTICE on all of your git repos? You'll find them listed in https://incubator.apache.org/clutch/resilientdb.html

Hi PJ, Yes. I have updated all.

Thanks a lot.

@cjcchen I have checked some git repos and they were not updated. I assume that you are hand modifying the files as part of creating the release. This is problematic.

• The files might not be correct for future RCs as the release manager might forget to hand modify them
• If the release manager is hand modifying the files in the source release, what is to say that they are not modifying other files
• most RCs contain commit IDs and possibly git tags so that people verifying the releases can verify that the release manager is not hand modifying files - it really breaks the circle of trust - and it is important build is reproducible - that someone else could build the release and you would get the same artifacts

[cjcchen]

@cjcchen could you update the NOTICE on all of your git repos? You'll find them listed in https://incubator.apache.org/clutch/resilientdb.html

Hi PJ, Yes. I have updated all.
Thanks a lot.

@cjcchen I have checked some git repos and they were not updated. I assume that you are hand modifying the files as part of creating the release. This is problematic.

• The files might not be correct for future RCs as the release manager might forget to hand modify them
• If the release manager is hand modifying the files in the source release, what is to say that they are not modifying other files
• most RCs contain commit IDs and possibly git tags so that people verifying the releases can verify that the release manager is not hand modifying files - it really breaks the circle of trust - and it is important build is reproducible - that someone else could build the release and you would get the same artifacts

Hi PJ,

Thanks for the clarification.
I have committed the updates while creating the release RC2.

I will double-check again if I miss some and attach the commit IDs in the threads.