On 30 January 2016 at 05:11, Robert Haas <robertmh...@gmail.com> wrote: > > Well, this gets at one of the problems here, which is that you can't > fix a commit message once the commit has been pushed. So even if we > all agreed in principle to a standard format, it's not clear that you > could enforce compliance with that format to a degree sufficient to > make machine-parseability a reality.
Yep, there's the rub in it. Commit messages are authoritative for the things that ARE found in commit messages. If making them authoritative for a whole bunch of things means it is necessary to force everyone to run some piece of commit-message- monitoring code against their own repo, and any failure to run the message monitoring code causes the project to fail to have authoritative information, then it should be clear that we've constructed something a wee bit too fragile. A thing plausible instead is to collect the authoritative-at-commit-time message information into an external system (hey, I wonder if anyone has some sort of structured data store implemented that could be good at this!), and then have a way to feed additional information into that system that would become the authoritative source for any requirements for the extra metadata. That, of course, smells like a database that draws metadata from git, and augments with further streams of inputs. There is certainly something problematic about assuming that we can *always* get supplementary data. Begs the question of how we shame people into going back and filling the blanks we wanted filled. It seems foolish to me to imagine that we can ensure that the data *always* arrives at commit time; any laziness there represents a permanent "data fault"; making it asynchronous shifts the problem to a different spot. I suspect we can only approach success on it, and get *partial* metadata, at best. If it's enough better than nothing, then maybe that's good enough. And I'll bet that the Commitfest database already contains a lot of the data desired to fill blanks... Further, if the point is to encourage reviews by making sure credit (and hence data to support GIVING credit) is given, then it is not inapropos for those keen on receiving credit to be responsible for marking off the patches they know they contributed to. That's less fragile than expecting all credit to be attached by the committer at commit time. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
