"commit ID" -> "Apache ID" Gary
On Tue, Jun 28, 2022, 06:24 Gary Gregory <[email protected]> wrote: > The way I've been using changes.xml is slightly different: I record my > commit ID in dev and in due-to I usually list whomever participated by > looking at the Jira and/or PR. > > Gary > > On Tue, Jun 28, 2022, 02:13 Ralph Goers <[email protected]> > wrote: > >> I don’t always check the changes.xml and during the frenzy of the CVE >> releases I probably >> didn’t look at all. >> >> But I don’t think it is wise to go back and change it. For one, we won’t >> be updating the sites >> of those past releases so modifying them would make the history in the >> new release not >> match the old releases. >> >> Usually Gary has been the only one to do this. I am not sure why. He has >> told me he plans >> to continue to do it but I am free to change ti before the release. So >> when I catch it I do. >> >> Ralph >> >> > On Jun 27, 2022, at 10:48 PM, Piotr P. Karwasz <[email protected]> >> wrote: >> > >> > Hi Ralph, >> > >> > >> > On Tue, 28 Jun 2022 at 01:40, Ralph Goers <[email protected]> >> wrote: >> >> In preparation for the release I am going through changes.xml and am >> finding some issues. >> >> 1. The dev attribute should always include the uid of the committer >> who performed the commit. >> >> 2. The due-to attribute should be used to acknowledge the individual >> who either submitted a PR >> >> or provided enough detailed information about the problem to make >> fixing it easy. It should >> >> never include the name of a committer or PMC member. We get our >> credit via the dev attribute. >> >> Notice that the wording here is “Thanks to John Doe”. To me it >> would look egotistical for the >> >> line to say that the dev is rgoers along with “Thanks to Ralph >> Goers”. Why do I need to thank >> >> myself? >> > >> > So, if I understand correctly, the `dev` attribute of an accepted PR >> > should contain the login of the committer that accepted it, while the >> > original author should be in `due-to`? >> > >> > There are many entries in the previous Log4j2 versions that have the >> > same issues you found in 2.18.0. Should we correct them? >> > >> > Piotr >> >>
