24/11/2022 18:34, Ferruh Yigit: > On 11/24/2022 5:26 PM, Thomas Monjalon wrote: > > 24/11/2022 18:21, Ferruh Yigit: > >> On 11/24/2022 3:44 PM, David Marchand wrote: > >>> From: Bruce Richardson <bruce.richard...@intel.com> > >>> > >>> Since a number of contributors to DPDK have submitted patches to DPDK > >>> under more than one email address, we should maintain a mailmap file to > >>> properly track their commits using "shortlog". > >>> > >>> It also helps fix up any mangled names, for example, with > >>> surname/firstname reversed, or with incorrect capitalization. > >>> By keeping this file in the DPDK repository, rather than committers > >>> maintaining their own copies, it allows individual contributors to edit > >>> it to update their own email address preferences if so desired. > >>> > >>> While at it, update our checkpatches.sh script and add some > >>> documentation to help new contributors. > >>> > >>> Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > >>> Signed-off-by: David Marchand <david.march...@redhat.com> > >> > >> <...> > >> > >>> @@ -148,6 +148,9 @@ Make your planned changes in the cloned ``dpdk`` > >>> repo. Here are some guidelines > >>> > >>> * Follow the :ref:`coding_style` guidelines. > >>> > >>> +* If you are a new contributor, or if your mail address changed, please > >>> update the ``.mailmap`` file. > >> > >> There is no benefit for new contributors to update .mailmap file, but it > >> adds another thing to update. > >> > >> I think it is simpler to keep .mailmap only for users that has multiple > >> email address in the git repo, and ask only from contributors in this > >> catagory to update the .mailmap instead of all contributors. > > > > We are doing checks on name and email. Typos are very common. > > So we are maintaining such a file privately. > > We would like to make it public so people can change it if needed. > > > > If it looks a problem for newcomers, we can reword the doc to say > > if they are missing in the file and not added themselves, > > it will be added with their first patch by maintainers. > > Is it better? > > > > ACK, this is an internal file for project maintenance, so I think better > to batch update it per release etc.. (This approach also may give easy > list of new contributors for that release.)
I prefer to squash the change with the first patch. So the check runs for next patch. In any case, we can get the list of new contributors easily this way.
