I’ve been thinking about this and related conversations and what sort of tooling is required to make it easier/happen and still function with the various workflows different communities have.
smart-apply-patch now has a —committer flag. I’ve been using it for the past few commits to see how it works out when given a git am message. Given s-a-p also pulls in the various plug-ins that test-patch supports (unification is good!), we could add a function to the bug system plug-ins to parse the issue and pull out who participated in the conversation. I don’t think the header is checksummed, so modifying the patch file’s msg header prior to commit might work. Worse case, we could try —amend. This does put us at the mercy of the bug systems, however. For the majority of cases, just scraping the web page generated for special text might work, especially for participation. Review information might be trickier given we’ll need to look for specially formatted text, and even then someone might slip in that isn’t ‘cleared’ for review. To combat that, we’d likely need a list of cleared reviewers… Doable, but … ugh. Such a rabbit hole. For Yetus, we *could* institute a “don’t commit your own patch” rule, but that means “fix on commit” goes out the window and puts additional burden on reviewers. But that doesn’t exactly help anyone else (or probably us, really, for that matter).
