On Mon, Aug 30, 2021 at 1:46 PM Oscar <[email protected]> wrote: > > On Thursday, 26 August 2021 at 22:26:10 UTC+1 Aaron Meurer wrote: >> >> On Thu, Aug 26, 2021 at 3:09 PM Chris Smith <[email protected]> wrote: >> > >> > > many PRs need to make changes to the end of the same file. A simple fix >> > > is to make it so that the changes are not at the end >> > >> > Can't you just put a decorator line (or comment?) on the last line so >> > anyone's name would come before that? >> >> I don't think that would fix it. Git can't automatically merge two >> changes in the exact same place in a file, the end or otherwise. > > > It's actually worse than I thought. The file also lists the exact number of > authors: > > https://github.com/sympy/sympy/blob/345c3d686c06703fad6990a61e76a5f7043a0760/AUTHORS#L7 > > If new contributors A and B open PRs at the same time. Each of them will run > the authors_update.py script and it will increase the number of authors by 1. > Since they both make the same change to the same line there won't be a merge > conflict but after merging both the number of authors will be incorrect > unless the authors_update.py script is run again. > > That also means that merging any one PR from a new contributor invalidates > all other open PRs from new contributors. We can fix that by changing that > line to say there are "more than X authors" and then X can just be updated at > release time. If we also switch to alphabetical ordering of authors then that > would eliminate most of the problem. The instructions for a new contributor > would just be to run the script once and merge conflicts would be unlikely.
I think we can remove the number line from the file. We can edit the script to print the number to the terminal so that if you want to know you can just run the script (or just count the lines, which isn't that hard). > > The alternative to alphabetical ordering in the AUTHORS file itself would be > to have a separate file that gives names in alphabetical ordering and then > that can be translated into an ordered list at release time. I think either > way we would need a step at release time if the file is going to list the > number of authors so maybe that's actually the best option. Perhaps in fact > the alphabetically ordered file can just be the .mailmap file but it would > need to list all authors whereas it currently lists only those who have > ambiguous commit metadata. > > Okay so here's a proposal: > > List all authors in .mailmap which can be sorted alphabetically by primary > name/email combination. New contributors have to add their name and email > address in there (plus any alternate name/email combinations used in their > commits). They should then run a script that sorts the file and commit and > push that change to .mailmap. CI checks that the mailmap lists all authors > and fails if not. Then at release time the AUTHORS file itself is updated > keeping the ordering system that is already in use. On the release branch we > can have CI fail if the AUTHORS file is not up to date but new contributors > don't usually open PRs for the release branch so conflicts are unlikely. In > future that would mean that merge conflicts around the AUTHORS file are > unlikely and we would always have an accurate list of names of contributors. > > Does that sound reasonable? I think so. As long as the script is idempotent so that you can always just run the script to make sure everything is sorted properly. I do think making the script interactive would be even better, so that people don't have to figure out how .mailmap works, but this should at least fix the merge conflict problems. Aaron Meurer > > Any change here will also lead to the same problem of merge conflicts for new > contributors with currently open PRs though. In fact some of those new > contributors who have recent open PRs right now have already been struggling > with this and would need to merge/rebase and rerun the script again. > > (The reason I haven't yet written detailed instructions for how to do this > outside this thread is that I expected that the process would need to be > changed almost immediately.) > > Oscar > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/6e4efe78-bc64-41fe-bf82-f0753a17cafcn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KYoau1enjgD6UZYyAT5aY9K78igcZ3LDmj9tGr2A%3DQQw%40mail.gmail.com.
