We could fix most "who reviews" problems by asking the user to confirm out choices, I think.
Filtering participation by "+1" or similar should help distinguish between folks with drive by commentary and those willing to be listed in "singed-off-by". For some communities, anyone can review. For those with a list of committers we can provide tooling on common practices, e.g. a pom that lists developers. On Oct 12, 2015 11:55 AM, "Allen Wittenauer" <[email protected]> wrote: > > 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).
