| Message ID | b9a602b606960a417d2c2db7516a2829f0802af1.1687088959.git.mail@cbaines.net |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#64151] etc: Stop making sendemail behave strangely. | expand |
Hi Chris, (Cc: Maxim.) Christopher Baines <mail@cbaines.net> skribis: > I noticed git send-email misbehaving, adding X-Debbugs-Cc headers that I > didn't intend to add. Some patches had X-Debbugs-Cc for myself, which is > irritating to me, and others were worse in that they X-Debbugs-Cc'ed other > people. > > * etc/git/gitconfig: Stop affecting sendemail. I think it was done on purpose, so that the team responsible for the code being changed would automatically be notified. I like the intention, though I understand one might find it a bit heavy-handed: we end up Cc’ing lots of people (and apparently this hasn’t resulted in an increase of review work, unfortunately). So I guess I can sympathize with both arguments in favor and arguments against this behavior. Thoughts? Ludo’.
Hi Chris, Ludovic Courtès <ludo@gnu.org> writes: > Hi Chris, > > (Cc: Maxim.) > > Christopher Baines <mail@cbaines.net> skribis: > >> I noticed git send-email misbehaving, adding X-Debbugs-Cc headers that I >> didn't intend to add. Some patches had X-Debbugs-Cc for myself, which is >> irritating to me, and others were worse in that they X-Debbugs-Cc'ed other >> people. >> >> * etc/git/gitconfig: Stop affecting sendemail. > > I think it was done on purpose, so that the team responsible for the > code being changed would automatically be notified. Indeed! The original idea behind teams was to subscribe to a more focused scope than the guix-patches list; and commit 1d77fd705b ("doc: Simplify contributing section by automating git configuration.") made it ping the teams automatically. It's documented in info '(guix) Sending a Patch Series': Notifying Teams ............... If your git checkout has been correctly configured (*note Configuring Git::), the ‘git send-email’ command will automatically notify the appropriate team members, based on the scope of your changes. This relies on the ‘etc/teams.scm’ script, which can also be invoked manually if you do not use the preferred ‘git send-email’ command to submit patches. To list the available actions of the script, you can invoke it via the ‘etc/teams.scm help’ command. For more information regarding teams, see *Note Teams::. > I like the intention, though I understand one might find it a bit > heavy-handed: we end up Cc’ing lots of people (and apparently this > hasn’t resulted in an increase of review work, unfortunately). It did for me in a limited way because I'm only part of the gnome-team :-). When Liliana's GNOME patches reach my INBOX I feel compelled to process them quickly. I'd otherwise probably easily miss them. I'd suggest people joining teams only do so if they actually have the bandwidth to help with the review of the scopes they cover to avoid feeling overwhelmed. It's easy to add/remove ourselves to a team. If you *really* don't want the default configured behavior to happen, you still can, by adding the '--no-header-cmd' option to your 'git send-email' invocation, although I'd prefer you use this with a lot of care, as I want to receive the notifications for the submissions touching the team I'm subscribed to :-) If there's something to improve such as not adding a CC to yourself, that's a good idea and can probably be done in etc/teams.scm. You can open an issue for it if you'd like to track its resolution. Does that clarify things? If it does and it's acceptable to you, please close this issue.
Am Montag, dem 26.06.2023 um 10:36 -0400 schrieb Maxim Cournoyer: > > I like the intention, though I understand one might find it a bit > > heavy-handed: we end up Cc’ing lots of people (and apparently this > > hasn’t resulted in an increase of review work, unfortunately). > > It did for me in a limited way because I'm only part of the gnome- > team :-). When Liliana's GNOME patches reach my INBOX I feel > compelled to process them quickly. I'd otherwise probably easily > miss them. Funny that you'd mention that because for me, debbugs notifications are pretty hit or miss. A lot of them end up filtered by our benevolent overlords without me having ever read them. > I'd suggest people joining teams only do so if they actually have the > bandwidth to help with the review of the scopes they cover to avoid > feeling overwhelmed. It's easy to add/remove ourselves to a team. > > If you *really* don't want the default configured behavior to happen, > you still can, by adding the '--no-header-cmd' option to your 'git > send-email' invocation, although I'd prefer you use this with a lot > of care, as I want to receive the notifications for the submissions > touching the team I'm subscribed to :-) I feel as though we won't find many members willing to cover a certain scope if they potentially have to be responsible for all of it. Like, despite being a member of the gnome and emacs teams, there are certain packages within that scope that I'm more familiar with than others. > If there's something to improve such as not adding a CC to yourself, > that's a good idea and can probably be done in etc/teams.scm. You > can open an issue for it if you'd like to track its resolution. > > Does that clarify things? If it does and it's acceptable to you, > please close this issue. Even with such a hypothetical --exclude-whomever switch added, I'd argue that it is wrong to magically install this configuration without any user interaction. The current setup also causes quite a number of false positives, like a package rename also causing changes in some other scope and hence notifying like five different teams all at once. Cheers
Hi Liliana, Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > Am Montag, dem 26.06.2023 um 10:36 -0400 schrieb Maxim Cournoyer: >> > I like the intention, though I understand one might find it a bit >> > heavy-handed: we end up Cc’ing lots of people (and apparently this >> > hasn’t resulted in an increase of review work, unfortunately). >> >> It did for me in a limited way because I'm only part of the gnome- >> team :-). When Liliana's GNOME patches reach my INBOX I feel >> compelled to process them quickly. I'd otherwise probably easily >> miss them. > Funny that you'd mention that because for me, debbugs notifications are > pretty hit or miss. A lot of them end up filtered by our benevolent > overlords without me having ever read them. Maybe you are mistaken about what X-Debbugs-CC does; it doesn't cause someone to be subscribed to a specific issue; it's only a CC alternative that is a bit nicer in that it will reply with the issue number in the reply path, which is mostly useful for new issues that haven't gotten a Debbugs number yet. So I don't think we should think of it as a "notification" mechanism, simply a smarter CC for Debbugs. >> I'd suggest people joining teams only do so if they actually have the >> bandwidth to help with the review of the scopes they cover to avoid >> feeling overwhelmed. It's easy to add/remove ourselves to a team. >> >> If you *really* don't want the default configured behavior to happen, >> you still can, by adding the '--no-header-cmd' option to your 'git >> send-email' invocation, although I'd prefer you use this with a lot >> of care, as I want to receive the notifications for the submissions >> touching the team I'm subscribed to :-) > I feel as though we won't find many members willing to cover a certain > scope if they potentially have to be responsible for all of it. Like, > despite being a member of the gnome and emacs teams, there are certain > packages within that scope that I'm more familiar with than others. There currently isn't a strong notion of "responsibility" associated with being in a team (although we could flesh one if people want it, as Ludo had suggested with the "two team members should gate changes to their domain by putting their LGTM on it" or similar); it's currently simply a means to be subscribed to a specific scope of the project, to be notified on the changes you are most likely to be interested in (and hopefully comment on/review/commit). >> If there's something to improve such as not adding a CC to yourself, >> that's a good idea and can probably be done in etc/teams.scm. You >> can open an issue for it if you'd like to track its resolution. >> >> Does that clarify things? If it does and it's acceptable to you, >> please close this issue. > Even with such a hypothetical --exclude-whomever switch added. It's not hypothetical, it exists and works today (--no-header-cmd). The only reason it doesn't appear in 'man git-send-email' is because we don't build the git doc from source. It's scheduled to appear in Git 2.41.0 [0] [0] https://lore.kernel.org/git/xmqqleh3a3wm.fsf@gitster.g/ > I'd argue that it is wrong to magically install this configuration without > any user interaction. The current setup also causes quite a number of > false positives, like a package rename also causing changes in some > other scope and hence notifying like five different teams all at once. I personally prefer the zero-config approach that maximizes the potential of etc/teams.scm and reduces the documentation burden, but of course I'm biased :-). I find the contribution process of Guix already complicated enough to not want to add more to it, and welcome automation.
Am Dienstag, dem 27.06.2023 um 21:14 -0400 schrieb Maxim Cournoyer: > Hi Liliana, > > Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > > Funny that you'd mention that because for me, debbugs notifications > > are pretty hit or miss. A lot of them end up filtered by our > > benevolent overlords without me having ever read them. > > Maybe you are mistaken about what X-Debbugs-CC does; it doesn't cause > someone to be subscribed to a specific issue; it's only a CC > alternative that is a bit nicer in that it will reply with the issue > number in the reply path, which is mostly useful for new issues that > haven't gotten a Debbugs number yet. So I don't think we should > think of it as a "notification" mechanism, simply a smarter CC for > Debbugs. I am not. Debbugs-CC'd mail simply ends up in the spam folder because Google sees that > > > > I'd argue that it is wrong to magically install this configuration > > without any user interaction. The current setup also causes quite > > a number of false positives, like a package rename also causing > > changes in some other scope and hence notifying like five different > > teams all at once. > > I personally prefer the zero-config approach that maximizes the > potential of etc/teams.scm and reduces the documentation burden, but > of course I'm biased :-). I find the contribution process of Guix > already complicated enough to not want to add more to it, and welcome > automation. There's nothing wrong with automation per se, but you are confusing automating your own process knowingly with automating someone else's process without their knowledge or permission. I'd also argue that your approach doesn't maximize etc/teams.scm, but rather makes it exhibit the weirdest behaviours imaginable by applying it blindly. Cheers
Hi Liliana, Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > Am Dienstag, dem 27.06.2023 um 21:14 -0400 schrieb Maxim Cournoyer: >> Hi Liliana, >> >> Liliana Marie Prikler <liliana.prikler@gmail.com> writes: >> > Funny that you'd mention that because for me, debbugs notifications >> > are pretty hit or miss. A lot of them end up filtered by our >> > benevolent overlords without me having ever read them. >> >> Maybe you are mistaken about what X-Debbugs-CC does; it doesn't cause >> someone to be subscribed to a specific issue; it's only a CC >> alternative that is a bit nicer in that it will reply with the issue >> number in the reply path, which is mostly useful for new issues that >> haven't gotten a Debbugs number yet. So I don't think we should >> think of it as a "notification" mechanism, simply a smarter CC for >> Debbugs. > I am not. Debbugs-CC'd mail simply ends up in the spam folder because > Google sees that OK, odd; I haven't noticed that kind of filtering using gmail. >> > >> > I'd argue that it is wrong to magically install this configuration >> > without any user interaction. The current setup also causes quite >> > a number of false positives, like a package rename also causing >> > changes in some other scope and hence notifying like five different >> > teams all at once. >> >> I personally prefer the zero-config approach that maximizes the >> potential of etc/teams.scm and reduces the documentation burden, but >> of course I'm biased :-). I find the contribution process of Guix >> already complicated enough to not want to add more to it, and welcome >> automation. > There's nothing wrong with automation per se, but you are confusing > automating your own process knowingly with automating someone else's > process without their knowledge or permission. I'd also argue that > your approach doesn't maximize etc/teams.scm, but rather makes it > exhibit the weirdest behaviours imaginable by applying it blindly. What is weird? People opt to be in a team to be notified; the default git configuration when submitting patches causes the submission to notify them when appropriate. I don't understand how that qualifies as as the "weirdest behaviour imaginable" ?
Am Freitag, dem 30.06.2023 um 23:03 -0400 schrieb Maxim Cournoyer: > > There's nothing wrong with automation per se, but you are confusing > > automating your own process knowingly with automating someone > > else's process without their knowledge or permission. I'd also > > argue that your approach doesn't maximize etc/teams.scm, but rather > > makes it exhibit the weirdest behaviours imaginable by applying it > > blindly. > > What is weird? People opt to be in a team to be notified; the > default git configuration when submitting patches causes the > submission to notify them when appropriate. I don't understand how > that qualifies as as the "weirdest behaviour imaginable" ? It's about the sending end rather than the receiving end, really. As a sender, if you have a series that "invades" the territory of several teams, each will get CC'd exactly on the patches that overlap with them. I argue, that this is the worst possible configuration. For a recent example, Christopher sent a series that just renames ruby everywhere. I got 08/24 because gnome-team receives changes to webkit. As a member of gnome-team I said LGTM, but I really only had that one mail to go of. If I don't investigate the full series, Christopher could have introduced a wrong ruby here; either by accident (typo) or maliciously, and no you wouldn't catch on from that single mail. Thus, at the very least, the cover letter ought to go to all teams who have major stakes in any particular patch. But here's the second thing: gnome-team doesn't have major stakes in a minor patch out of twenty-four. With the current automation in place, users unknowingly and without ever intending to alert team attention to where it wouldn't be needed in a manner that leaves major context clues to be found in the aether. I don't think this "maximizes" the potential of teams in any way whatsoever. Cheers
Hi Liliana, Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > Am Freitag, dem 30.06.2023 um 23:03 -0400 schrieb Maxim Cournoyer: >> > There's nothing wrong with automation per se, but you are confusing >> > automating your own process knowingly with automating someone >> > else's process without their knowledge or permission. I'd also >> > argue that your approach doesn't maximize etc/teams.scm, but rather >> > makes it exhibit the weirdest behaviours imaginable by applying it >> > blindly. >> >> What is weird? People opt to be in a team to be notified; the >> default git configuration when submitting patches causes the >> submission to notify them when appropriate. I don't understand how >> that qualifies as as the "weirdest behaviour imaginable" ? > It's about the sending end rather than the receiving end, really. As a > sender, if you have a series that "invades" the territory of several > teams, each will get CC'd exactly on the patches that overlap with > them. I argue, that this is the worst possible configuration. > > For a recent example, Christopher sent a series that just renames ruby > everywhere. I got 08/24 because gnome-team receives changes to webkit. > As a member of gnome-team I said LGTM, but I really only had that one > mail to go of. If I don't investigate the full series, Christopher > could have introduced a wrong ruby here; either by accident (typo) or > maliciously, and no you wouldn't catch on from that single mail. Maybe we just need to agree that each patch should have a LGTM unless the reviewer explicitly mentioned e.g. "LGTM for this patch and the previous ones". I believe that's already the way most reviewers understand it but documenting this explicitly wouldn't hurt. Then even if you review a single patch with no context your LGTM can still be useful for that single patch and not taken erroneously as an overall badge of approval. > Thus, at the very least, the cover letter ought to go to all teams who > have major stakes in any particular patch. But here's the second > thing: gnome-team doesn't have major stakes in a minor patch out of > twenty-four. > > With the current automation in place, users unknowingly and without > ever intending to alert team attention to where it wouldn't be needed > in a manner that leaves major context clues to be found in the aether. > I don't think this "maximizes" the potential of teams in any way > whatsoever. I think patches touching overlapping scopes will be the edge case rather than the common one, so I don't see it as a serious issue, especially if we explicit the LGTM as suggested above. What do you think?
Hi, Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > Even with such a hypothetical --exclude-whomever switch added, I'd > argue that it is wrong to magically install this configuration without > any user interaction. Maybe that’s the main grief: that the new config was suddenly installed without fellow hackers realizing it (I, for one, wondered initially what magic made ‘git send-email’ Cc: all my friends :-)). Perhaps one way out is to suggest it in the manual without installing it automatically? WDYT, Maxim? (Independently of that, we’ll have to discuss patch review again. We believed one problem was that potential reviewers wouldn’t notice patches in their area. That’s arguably no longer the case, yet this hasn’t had any noticeable effect in terms of review activity. How should we approach that?) Thanks, Ludo’.
Hi Ludo, Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > >> Even with such a hypothetical --exclude-whomever switch added, I'd >> argue that it is wrong to magically install this configuration without >> any user interaction. > > Maybe that’s the main grief: that the new config was suddenly installed > without fellow hackers realizing it (I, for one, wondered initially what > magic made ‘git send-email’ Cc: all my friends :-)). > > Perhaps one way out is to suggest it in the manual without installing it > automatically? WDYT, Maxim? I still think it has more value by being automatically installed, as that way the pre-push hook that prevents unsigned commit is also configured automatically, and new contributors would be likely to not have it configured (by having missed it from the manual). I see this similar to the .dir-locals.el file that automatically setups (there's a prompt, but its design forces you into accepting it or being repeatedly bothered ad aeternam). If there are concrete issues with it, I think we should a) report them and b) look into fixing them. > (Independently of that, we’ll have to discuss patch review again. We > believed one problem was that potential reviewers wouldn’t notice > patches in their area. That’s arguably no longer the case, yet this > hasn’t had any noticeable effect in terms of review activity. How > should we approach that?) The teams are still nascent, and it's summer time. I think we need to give it some time and encourage more people to join or create new teams and get familiar with the recently introduced/documented branch-based updates :-).
Am Donnerstag, dem 06.07.2023 um 11:49 -0400 schrieb Maxim Cournoyer: > Hi Ludo, > > Ludovic Courtès <ludo@gnu.org> writes: > > > Hi, > > > > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > > > > > Even with such a hypothetical --exclude-whomever switch added, > > > I'd argue that it is wrong to magically install this > > > configuration without any user interaction. > > > > Maybe that’s the main grief: that the new config was suddenly > > installed without fellow hackers realizing it (I, for one, wondered > > initially what magic made ‘git send-email’ Cc: all my friends :-)). > > > > Perhaps one way out is to suggest it in the manual without > > installing it automatically? WDYT, Maxim? > > I still think it has more value by being automatically installed, as > that way the pre-push hook that prevents unsigned commit is also > configured automatically, and new contributors would be likely to not > have it configured (by having missed it from the manual). > > I see this similar to the .dir-locals.el file that automatically > setups (there's a prompt, but its design forces you into accepting it > or being repeatedly bothered ad aeternam). There is also a way of enforcing a "no", though. And in particular, the version-controlled .dir-locals.el has only been really supported since the introduction of .dir-locals-2.el, which allows local changes. > If there are concrete issues with it, I think we should a) report > them and b) look into fixing them. Such as the concrete issue that it changes our workflow without asking? Mind you, that I'm only not affected because I've been format-patching manually for a long time at this point. Cheers >
Hi Liliana, Liliana Marie Prikler <liliana.prikler@gmail.com> writes: [...] >> If there are concrete issues with it, I think we should a) report >> them and b) look into fixing them. > Such as the concrete issue that it changes our workflow without > asking? The suggestion to notify team members was only recently introduced in 8fed83 (doc: contributing: Expand "Sending a Patch Series".) 1d77fd ("doc: Simplify contributing section by automating git configuration.") made it happen transparently by default. You can still use 'git send-email --no-header-cmd' if you really must disable the new behavior. > Mind you, that I'm only not affected because I've been format-patching > manually for a long time at this point. Not that the pre-configured header-cmd ("etc/teams.scm cc-members-header-cmd") gets used when you invoke 'git send-email'; it doesn't matter if the patches were 'git patch-format'd manually before or not.
Hello! It just occurred to me that we might have a reasonable tradeoff at hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add, say, X-Guix-Team: headers. That way, team members would be free to filter incoming messages however they want. How does that sound? Of course if team members don’t pay attention to that header, we’re back to square one, but hopefully that won’t be the case. Ludo’.
Am Montag, dem 10.07.2023 um 23:21 +0200 schrieb Ludovic Courtès: > Hello! > > It just occurred to me that we might have a reasonable tradeoff at > hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add, > say, X-Guix-Team: headers. That way, team members would be free to > filter incoming messages however they want. > > How does that sound? > > Of course if team members don’t pay attention to that header, we’re > back to square one, but hopefully that won’t be the case. But how would that header work in practice? Assuming the mails aren't automatically forwarded, we would need another interface, e.g. mumi to handle it. Plus, the issue of tagging a single patch in a series would still apply, would it not? Cheers
Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > Am Montag, dem 10.07.2023 um 23:21 +0200 schrieb Ludovic Courtès: >> Hello! >> >> It just occurred to me that we might have a reasonable tradeoff at >> hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add, >> say, X-Guix-Team: headers. That way, team members would be free to >> filter incoming messages however they want. >> >> How does that sound? >> >> Of course if team members don’t pay attention to that header, we’re >> back to square one, but hopefully that won’t be the case. > But how would that header work in practice? Assuming the mails aren't > automatically forwarded, we would need another interface, e.g. mumi to > handle it. Plus, the issue of tagging a single patch in a series would > still apply, would it not? Hi! The header in itself wouldn’t have any effect: it’s up to recipients to configure their email client to filter messages as they see fit. So in that sense it’d be less intrusive. Mumi could also display a tag based on this and let people select only issues relevant to a specific team. That would be an improvement over what we have. Thoughts? Ludo’.
Am Freitag, dem 14.07.2023 um 15:21 +0200 schrieb Ludovic Courtès: > Hi! The header in itself wouldn’t have any effect: it’s up to > recipients to configure their email client to filter messages as they > see fit. So in that sense it’d be less intrusive. IMHO, it'd be as intrusive as before on the sending end, but less visible; we still get the same false positives, but we'd be displaying them somewhere instead of sending out mails. That would be less annoying on the receiving end, but mumi's search already isn't that great and I don't think automatic subpar tagging would improve it. > Thoughts? I think what we really need here is not a dumb tool that just stamps a bunch of patches in some way, but one that is aware of the context of a series. Does a significant number of patches touch files associated with some team? Flag it. Are there any packages that cause a high number of rebuilds? Mention the X-team branch. I also think the tool ought to explain what it does (perhaps offering a flag to skip explanations for expert users) and be accompanied with proper documentation for a manual workflow on which it is based. Cheers
Hi Ludovic, Ludovic Courtès <ludo@gnu.org> writes: > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > >> Am Montag, dem 10.07.2023 um 23:21 +0200 schrieb Ludovic Courtès: >>> Hello! >>> >>> It just occurred to me that we might have a reasonable tradeoff at >>> hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add, >>> say, X-Guix-Team: headers. That way, team members would be free to >>> filter incoming messages however they want. >>> >>> How does that sound? >>> >>> Of course if team members don’t pay attention to that header, we’re >>> back to square one, but hopefully that won’t be the case. >> But how would that header work in practice? Assuming the mails aren't >> automatically forwarded, we would need another interface, e.g. mumi to >> handle it. Plus, the issue of tagging a single patch in a series would >> still apply, would it not? > > Hi! The header in itself wouldn’t have any effect: it’s up to > recipients to configure their email client to filter messages as they > see fit. So in that sense it’d be less intrusive. It could perhaps be used *in addition* to the X-Debbugs-CC headers, but I don't see it as a replacement, because e.g. for a single patch send directly to guix-patches@gnu.org, X-Debbugs-CC does the nice thing of retrieving the bug ID and adding its corresponding email into the forwarded mail, so that users see which bug the mail was attached to. > Mumi could also display a tag based on this and let people select only > issues relevant to a specific team. That would be an improvement over > what we have. > > Thoughts? I am still not convinced something deserves to be changed here; the problems reported so far, unless I'm missing something, were: 1. It's weird that send-email cause people to be CC'd itself 2. It can be confusing when a larger series touches multiple teams I think 1. mostly results from the initial surprise that send-email now behaves that way, but I don't see how it's a bad behavior to reach out to team members automatically. The process being automated should yield the same result as if a user called the etc/teams.scm script and placed the --add-header arguments themselves. 2. Is more of an edge case. I think if we have a policy of adding a LGTM *per patch* or 'LGTM for whole the series' it'd solve the immediate concern. Having a X-Guix-Team as proposed by Ludo *also* added could provide a bit more context in doubt. I'd be interested to hear back from Chris, which originally opened issue, in light of the above.
Hi Liliana, Liliana Marie Prikler <liliana.prikler@gmail.com> writes: [...] > I think what we really need here is not a dumb tool that just stamps a > bunch of patches in some way, but one that is aware of the context of a > series. Does a significant number of patches touch files associated > with some team? Flag it. Are there any packages that cause a high > number of rebuilds? Mention the X-team branch. I also think the tool > ought to explain what it does (perhaps offering a flag to skip > explanations for expert users) and be accompanied with proper > documentation for a manual workflow on which it is based. We already have such a tool: 'mumi send-email'. It also makes use of the etc/teams.scm script, so of the tagging is of bad quality, we should fix it there.
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: >> Mumi could also display a tag based on this and let people select only >> issues relevant to a specific team. That would be an improvement over >> what we have. >> >> Thoughts? > > I am still not convinced something deserves to be changed here; the > problems reported so far, unless I'm missing something, were: > > 1. It's weird that send-email cause people to be CC'd itself > 2. It can be confusing when a larger series touches multiple teams > > I think 1. mostly results from the initial surprise that send-email now > behaves that way, but I don't see how it's a bad behavior to reach out > to team members automatically. The process being automated should yield > the same result as if a user called the etc/teams.scm script and placed > the --add-header arguments themselves. > > 2. Is more of an edge case. I think if we have a policy of adding a > LGTM *per patch* or 'LGTM for whole the series' it'd solve the immediate > concern. Having a X-Guix-Team as proposed by Ludo *also* added could > provide a bit more context in doubt. > > I'd be interested to hear back from Chris, which originally opened > issue, in light of the above. On the 2nd point above, I've also felt the effects of the other side, where it's irritating that mail that used to be on mailing lists has moved in to my inbox. I can still automatically file away the initial email, but then people typically CC me directly when replying. I'm obviously OK with this when people directly want my input or if I'm already involved in the conversation, but this CC thing has extended that to most/any patch submissions that are detected overlapping with teams I'm in. Maybe this is just because of the email address I used for teams. I've now gone and changed this from mail@cbaines.net to guix@cbaines.net, which comes to the same place, but I'll hopefully be able to use the different address to separate out the emails appropriately.
Hi Chris, Christopher Baines <mail@cbaines.net> writes: > Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > >>> Mumi could also display a tag based on this and let people select only >>> issues relevant to a specific team. That would be an improvement over >>> what we have. >>> >>> Thoughts? >> >> I am still not convinced something deserves to be changed here; the >> problems reported so far, unless I'm missing something, were: >> >> 1. It's weird that send-email cause people to be CC'd itself >> 2. It can be confusing when a larger series touches multiple teams >> >> I think 1. mostly results from the initial surprise that send-email now >> behaves that way, but I don't see how it's a bad behavior to reach out >> to team members automatically. The process being automated should yield >> the same result as if a user called the etc/teams.scm script and placed >> the --add-header arguments themselves. >> >> 2. Is more of an edge case. I think if we have a policy of adding a >> LGTM *per patch* or 'LGTM for whole the series' it'd solve the immediate >> concern. Having a X-Guix-Team as proposed by Ludo *also* added could >> provide a bit more context in doubt. >> >> I'd be interested to hear back from Chris, which originally opened >> issue, in light of the above. > > On the 2nd point above, I've also felt the effects of the other side, > where it's irritating that mail that used to be on mailing lists has > moved in to my inbox. I can still automatically file away the initial > email, but then people typically CC me directly when replying. > > I'm obviously OK with this when people directly want my input or if I'm > already involved in the conversation, but this CC thing has extended > that to most/any patch submissions that are detected overlapping with > teams I'm in. Notifying team members of a patch touching their scope is the intended behavior of the teams mechanism. > Maybe this is just because of the email address I used for teams. I've > now gone and changed this from mail@cbaines.net to guix@cbaines.net, > which comes to the same place, but I'll hopefully be able to use the > different address to separate out the emails appropriately. Of course this behavior now being automated, if you are part of many teams, the amount of emails reaching your inbox may be higher than it used to be. If the flux is too large for you to process, I'd recommend you review and perhaps trim your current teams subscription. One of the expected side-effect of notifying team members with etc/teams.scm is that it should improve reviews. Keeping our team scopes more focus (and encouraging active participation of new team members) should help reduce the load in the long run.
Hi, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: [...] >> I'm obviously OK with this when people directly want my input or if I'm >> already involved in the conversation, but this CC thing has extended >> that to most/any patch submissions that are detected overlapping with >> teams I'm in. > > Notifying team members of a patch touching their scope is the intended > behavior of the teams mechanism. > >> Maybe this is just because of the email address I used for teams. I've >> now gone and changed this from mail@cbaines.net to guix@cbaines.net, >> which comes to the same place, but I'll hopefully be able to use the >> different address to separate out the emails appropriately. > > Of course this behavior now being automated, if you are part of many > teams, the amount of emails reaching your inbox may be higher than it > used to be. If the flux is too large for you to process, I'd recommend > you review and perhaps trim your current teams subscription. One of the > expected side-effect of notifying team members with etc/teams.scm is > that it should improve reviews. Keeping our team scopes more focus (and > encouraging active participation of new team members) should help reduce > the load in the long run. Are you OK with closing this issue?
diff --git a/etc/git/gitconfig b/etc/git/gitconfig index 907ad01804..11b8e40cab 100644 --- a/etc/git/gitconfig +++ b/etc/git/gitconfig @@ -11,8 +11,3 @@ [pull] rebase = true - -[sendemail] - to = guix-patches@gnu.org - headerCmd = etc/teams.scm cc-members-header-cmd - thread = no