I read the whole sentence, but i only felt the need to response to part of it.
If it's important to you that i repsond to the whole thing...
We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing.
commit messages and CHANGES entries today are frequently the same but not always (examples: most people don't include the contributors names in the commit msg, but we do in CHANGES, if i'm merging to another branch i always include the source rev in the commit message but obviously never in CHANGES, sometimes people commit things for multiple issues at once, and use a isngle commit message refering to all of the affected issue#s, but split them out and provide more detail in CHANGES, etc...)
It's been convention because it worked well, but it's never been a rule and it's never been enforced.
we're now having a conversation about how we want to change our conventions and general practices to better integrate with github – and that's fine and i'm all in favor of it, but since by definition this a conversation about changing conventions I don't see why we it's a bad idea to consider tweaking one convention (keeping commit messages close to CHANGES entries) slightly in order to have better records as we amend another convetion (refering to github pull requests in commit msgs and/or CHANGES)
If all github cares about is seeing "pull request #xxx" in the commit message, then what's wrong with using "pull request #xxx" in the commit msg – but in CHANGES.txt (where we are trying to keep a long term human permanent record of where stuff comes from and why) also mention, in some way, in some part of the CHANGES entry that the patch was contributed via github? (so X years from now when we are getting contributions via MercurialHub and BitBucket mirrors we'll know what the fuck we were talking about back in 2014)
Or let's put it another way and consider the more general problem...
Imagine a situation where we have a Jira issue tracking a bug, where people have heavily discussed the bug and explained it's symptoms and what's bad about it, and how it affects things, and you can work around it in some situations but not in others. (ie: stuff people might care about when reading CHANGES.txt to know if it's something that may affect them and their upgrade testing) and then someone comes along and contributes a fix, but instead of attaching it to the jira, they submit it as a pull request.
how should that be tracked in CHANGES.txt?
I would suggest that something like this may be a good convention moving forward...
LUCENE-XYZ: Fixed a bug in the HuperDuperMergeDestroyer that would cause merges to not be destroyed if it was a tuesday and you live in Angola (github pull request #ABC)
* LUCENE-XYZ: Fixed a bug in the HuperDuperMergeDestroyer that would cause
merges to not be destroyed if it was a tuesday and you live in Angola
(Sally Contributor via Jim Commiter - github pull request #ABC)
With all of the changes2html hyperlinking you might expect.
If there is no Jira, leave that part out (just like we do today). If there is no Contributor, leavethat part out (just like we do today). If there is no github pull request, leave that part out (just like we do today)