"Richard Earnshaw (lists)" <richard.earns...@arm.com> writes:
> On 24/06/2024 22:34, Sam James via Gcc wrote: >> Hi! >> >> This comes up in #gcc on IRC every so often, so finally >> writing an RFC. >> >> What? >> --- >> >> I propose that MAINTAINERS be modified to be of the form, >> adding an extra field for their GCC/sourceware account: >> <Name> <Email> <Email on gcc.gnu.org BZ / sourceware >> account> >> Joe Bloggs joeblo...@example.com jblo...@gcc.gnu.org >> >> Further, that the field must not be blank (-> must have a BZ account; >> there were/are some without at all)! >> >> Why? >> --- >> >> 1) This is tied to whether or not people should use their committer email >> on Bugzilla or a personal email. A lot of people don't seem to use their >> committer email (-> no permissions) and end up not closing bugs, so >> pinskia (and often myself these days) end up doing it for them. >> >> 2) It's standard practice to wish to CC the committer of a bisect result >> - or to CC someone who you know wrote patches on a subject area. Doing >> this on Bugzilla is challenging when there's no map between committer >> <-> BZ account. >> >> Specifically, there are folks who have git committer+author as >> joeblo...@example.com (or maybe even coold...@example.com) where the >> local part of the address has *no relation* to their GCC/sw account, >> so finding who to CC is difficult without e.g. trawling through gcc-cvs >> mails or asking overseers for help. >> >> Summary >> --- >> >> TL;DR: The proposal is: >> >> 1) MAINTAINERS should list a field containing either the gcc.gnu.org >> email in full, or their gcc username (bikeshedding semi-welcome); >> >> 2) It should become a requirement that to be in MAINTAINERS, one must >> possess a Bugzilla account (ideally using their gcc.gnu.org email). >> >> thanks, >> sam > > > How does this work for cases where: > 1) Committer is pushing to a personal or other copy of the repository > 2) Developers who have used the 'fetch' model to pull another developer's > patches from 1 above? > > Forcing these to be rewritten will break the hashes. To be clear, my proposal doesn't touch on the actual git metadata people should use, although Arsen's followup one does. > > R. thanks, sam
