Gerrit mails, from address, verbosity, etc
Hi, we have the first round of contributions through Gerrit and maybe now is a good time to look at the mail setup. My goal was to: * Have diff's/patches be sent to the MailingList to see what is going on * Have comments be sent to the MailingList to have people learn from feedback In terms of technology Gerrit offers us the following notifications[1] new_changes Somebody created a new change new_patchsets Somebody updated/added a patch(set) to a change all_comments Somebody but jenkins commented submitted_changes Somebody has pushed the submit button and it is in abandoned_changes Somebody gave up on the change all Everything Currently we are using "all" and maybe we want to limit it to "new_patchsets" and "all_comments". "all_comments" is a bit troublesome as it includes empty messages like "+2" with actual review comments. What would be the close to ideal solution? * Be able to reply by mail to changes (most likely not to come) * Mails sent have the author name as From (but gerrit mail address)? * Empty mails like "+2" not sent to the Mailinglist? * Subject changed? [PATCH] and omit branch name? Or omit project name? Other proposals? Move it to a new mailinglist and leave OpenBSC as low-volume mailinglist? comments? feedback? ideas? holger [1] https://gerrit-review.googlesource.com/Documentation/user-notify.html#notify...
On Mon, May 16, 2016 at 10:41:48AM +0200, Holger Freyther wrote:
Hi,
we have the first round of contributions through Gerrit and maybe now is a good time to look at the mail setup. My goal was to:
* Have diff's/patches be sent to the MailingList to see what is going on * Have comments be sent to the MailingList to have people learn from feedback
In terms of technology Gerrit offers us the following notifications[1]
new_changes Somebody created a new change new_patchsets Somebody updated/added a patch(set) to a change all_comments Somebody but jenkins commented submitted_changes Somebody has pushed the submit button and it is in abandoned_changes Somebody gave up on the change all Everything
Currently we are using "all" and maybe we want to limit it to "new_patchsets" and "all_comments". "all_comments" is a bit troublesome as it includes empty messages like "+2" with actual review comments.
I like to see everything on a mailing list so that I get updated as I read mails in my mail client, without having to navigate to some other place and klick 100 times. I was thinking though about local filtering to direct the pretty high volume and for my taste too verbose (s.b.) messages in a separate mail folder. Maybe having a separate mailing list would make sense there for easier filtering. Also the 'no-reply' sender is cumbersome, it should be sent by or have a Reply-To: header so that replies go back to the mailing list instead of individual recipients. (whether openbsc@ or a new gerrit ML, don't know) Details on my "too verbose" opinion: I'd prefer to have none of the automatic palaver words in the mails, and the subject should show the nature of the notification, with only project name and log summary. Ideally I want to see events of a given patch in a single mail thread on the first glance: [PATCH] openbsc: frobnicate fringlebroods ├─> [+0] openbsc: frobnicate fringlebroods ├─> [-1] openbsc: frobnicate fringlebroods ├─> [PATCH] openbsc: frobnicate fringlebroods (#2) ├─> [+2] openbsc: frobnicate fringlebroods (#2) └─> [MERGED] openbsc: frobnicate fringlebroods (#2) and the meat of the events in the mail body, without cruft. (Not sure how much of it is easily available... just brainstorming) For example: (1) Instead of Subject: Change in osmo-pcu[master]: Restructure sources Body: From Max <msuraev@sysmocom.de>: Max has uploaded a new change for review. https://gerrit.osmocom.org/58 Change subject: Restructure sources I would prefer Subject: [PATCH] osmo-pcu: Restructure sources Body: New patch: https://gerrit.osmocom.org/58 By: msuraev <log msg + diff> (2) Instead of Subject: Change in osmo-iuh[master]: attempt to fix parallel build, improve AM logic Body: From ahuemer <alexander.huemer@xx.vu>: Hello Jenkins Builder, Holger Freyther, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/65 to look at the new patch set (#2). I would prefer Subject: [+0] osmo-iuh: attempt to fix parallel build, improve AM logic Body: New comment: https://gerrit.osmocom.org/65 By: ahuemer <actual comment> (3) Instead of Subject: Change in openbsc[master]: db.c: implemented incremental migration Body: Holger Freyther has submitted this change and it was merged.[...] I would prefer Subject: [MERGED] openbsc: db.c: implemented incremental migration Body: Merged: https://gerrit.osmocom.org/99 </end-of-mail> (all other info is available in previous mails) The question though is, if the mail subjects vary depending on new patch/comment/merged/..., will mail clients still show them in the same thread? Maybe the already present In-Reply-To: header is sufficient there? ~Neels
On 17 May 2016, at 01:48, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
[PATCH] openbsc: frobnicate fringlebroods ├─> [+0] openbsc: frobnicate fringlebroods ├─> [-1] openbsc: frobnicate fringlebroods ├─> [PATCH] openbsc: frobnicate fringlebroods (#2) ├─> [+2] openbsc: frobnicate fringlebroods (#2) └─> [MERGED] openbsc: frobnicate fringlebroods (#2)
https://gist.github.com/foerster/1861014 so maybe all but the +0/-1/+2 is possible. In terms of GIT [PATCH v2] would probably be the more "correct" way. I am trying to understand the template logic more but the email code is very self contained in Gerrit and I am confident to modify templates and code in reasonable amount of time. I have already found a way to have a more nice 'From' of the mail and shorten one template. Let me see how much effort it is to get the verdict in it. And to do bikeshedding do you think we should support +0 and -0 ;) holger
Hi. Lot's of projects have separate mailing list *-commits (or smth like that) for such auto-generated emails. I like this option most - it helps to keep large volume of emails which are of interest to rather small group of developers clearly separated from much small number of emails which might be of general interest for users. On 05/16/2016 10:41 AM, Holger Freyther wrote:
Hi,
we have the first round of contributions through Gerrit and maybe now is a good time to look at the mail setup. My goal was to:
* Have diff's/patches be sent to the MailingList to see what is going on * Have comments be sent to the MailingList to have people learn from feedback
In terms of technology Gerrit offers us the following notifications[1]
new_changes Somebody created a new change new_patchsets Somebody updated/added a patch(set) to a change all_comments Somebody but jenkins commented submitted_changes Somebody has pushed the submit button and it is in abandoned_changes Somebody gave up on the change all Everything
Currently we are using "all" and maybe we want to limit it to "new_patchsets" and "all_comments". "all_comments" is a bit troublesome as it includes empty messages like "+2" with actual review comments.
What would be the close to ideal solution?
* Be able to reply by mail to changes (most likely not to come) * Mails sent have the author name as From (but gerrit mail address)? * Empty mails like "+2" not sent to the Mailinglist? * Subject changed? [PATCH] and omit branch name? Or omit project name?
Other proposals? Move it to a new mailinglist and leave OpenBSC as low-volume mailinglist?
comments? feedback? ideas?
holger
[1] https://gerrit-review.googlesource.com/Documentation/user-notify.html#notify...
-- Max Suraev <msuraev@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi Max, Holger and others, On Tue, May 17, 2016 at 10:01:38AM +0200, Max wrote:
Lot's of projects have separate mailing list *-commits (or smth like that) for such auto-generated emails. I like this option most - it helps to keep large volume of emails which are of interest to rather small group of developers clearly separated from much small number of emails which might be of general interest for users.
Agreed, and we already have that with the osmocom-commitlog mailing list. I'm not sure how this list is used in context of the new gerrit setup. Does it only receive the 'accepted/approved' changes that were merged into master. Holger? We should definitely still keep pushing notifications to that list, IMHO. The reason for having patch submissions + related discussions on the main mailing list is IMHO exactly to ensure that people who are not using gerrit every day are able to follow what's happening and able to provide their feedback. I would thus be in favor of having the following on the main mailing list:
new_changes Somebody created a new change new_patchsets Somebody updated/added a patch(set) to a change
and not have those:
all_comments Somebody but jenkins commented submitted_changes Somebody has pushed the submit button and it is in abandoned_changes Somebody gave up on the change
Currently we are using "all" and maybe we want to limit it to "new_patchsets" and "all_comments". "all_comments" is a bit troublesome as it includes empty messages like "+2" with actual review comments.
I would think that new_patchsets possibly with new_changes should be in, but for comments I would rather disable them. The "Foo has voded +2" mails are absolutely not aceptable to me. I'd rather have all comment notifications disabled than to have those on the list. Even if we can filter, I'm not sure if we want all the comments on the list or not... -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 17 May 2016, at 11:42, Harald Welte <laforge@gnumonks.org> wrote:
Agreed, and we already have that with the osmocom-commitlog mailing list. I'm not sure how this list is used in context of the new gerrit setup. Does it only receive the 'accepted/approved' changes that were merged into master. Holger? We should definitely still keep pushing notifications to that list, IMHO.
Once it is submitted in Gerrit, it will be replicated to git.osmocom.org at which point the usual commit message will be generated.
and not have those:
all_comments Somebody but jenkins commented
The "Foo has voded +2" mails are absolutely not aceptable to me. I'd rather have all comment notifications disabled than to have those on the list. Even if we can filter, I'm not sure if we want all the comments on the list or not...
Let's take the "moving" of the DTX VTY command from global to per BTS. I said that we should not break old/currently used configuration files, pointed to DEFUN_DEPRECATED and Max found .HIDDEN_STR (.HIDDEN_TEXT?). I think it would still be nice (in terms of learning) to see them even for changes I do not review. Is there a middle ground? A separate mailinglist? Add some code to create a "all_human_comments"? that include a personal comment (and only such?)? holger
On Tue, May 17, 2016 at 11:42:25AM +0200, Harald Welte wrote:
I would thus be in favor of having the following on the main mailing list:
new_changes Somebody created a new change new_patchsets Somebody updated/added a patch(set) to a change
and not have those:
all_comments Somebody but jenkins commented submitted_changes Somebody has pushed the submit button and it is in abandoned_changes Somebody gave up on the change
Maybe we can have a verbose mailing list with all notifications, and only the sparse new_* notifications copied to the main mailing list? :/ I see a conflict though: when we go on to use the gerrit inline commenting infrastructure, and others comment on patches on the main ML, we have comments in several "places" with possible parallel conversations and mixups. So IMHO unless we copy the gerrit commenting to the ML, we should actually completely drop gerrit commenting and only use email for that. I would like to read comments without having to navigate the gerrit system -- whatever that means in terms of what we use. gerrit has features that patchwork doesn't, but I don't exactly burst out in cheers about it ;) What actually is the workflow for Jane Doe sending a [PATCH] email to e.g. openbsc@? Do we ask Ms. Doe to create a gerrit account and re-submit? Does a core dev have to proxy it to gerrit for her? Re Holger, about the +0 -0 feature in the subjects: completely not important, a constant string indicating a comment and/or vote nature would be plenty. ~Neels
Dear all, I'm not very happy with the many gerrit mails on this list. By now it is dificult to point out an actual discussion thread among all the many gerrit auto-generated messages. The point is: You cannot reasonably respond to a gerrit-generated mail by replying to it, so you don't need to read it in the same folder/location/point-in-time as the actual human-initiated mails/discussion. So I think I'm now in favor of having all the gerrit mails removed from tis list and have them on a separate list. What's the general feeling of others about it? -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 02 Jun 2016, at 13:53, Harald Welte <laforge@gnumonks.org> wrote:
Dear all,
Hi!
I'm not very happy with the many gerrit mails on this list. By now it is dificult to point out an actual discussion thread among all the many gerrit auto-generated messages.
The point is: You cannot reasonably respond to a gerrit-generated mail by replying to it, so you don't need to read it in the same folder/location/point-in-time as the actual human-initiated mails/discussion.
So I think I'm now in favor of having all the gerrit mails removed from tis list and have them on a separate list.
What's the general feeling of others about it?
I agree it is too many mails. I would like to see the patch (and updated patches) and comments to it. "Merged", "+2" with no human comment should probably not be here. Is this something you can deal with? holger PS: Don't hold your breath but mail -> gerrit using the http API (and ignoring who commented, unless I can forge that easily) seems quite easy to do as well.
Hi Holger, On Thu, Jun 02, 2016 at 02:17:51PM +0200, Holger Freyther wrote:
I agree it is too many mails. I would like to see the patch (and updated patches) and comments to it. "Merged", "+2" with no human comment should probably not be here. Is this something you can deal with?
I _think_ so. But in the case of doubt, it could all be moved. I think if the list has 90% patches + reviews, it will be uninteresting for people outside the development team to subscribe to it, and users could feel intimidated to actually raise questions. At the same time, the project is too small to start separate -user and -devel mailing lists, either. But let's see what other have to say about it.
PS: Don't hold your breath but mail -> gerrit using the http API (and ignoring who commented, unless I can forge that easily) seems quite easy to do as well.
Great, but I think it's not the most important issue to spend time on at this point... -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Thu, Jun 02, 2016 at 02:40:19PM +0200, Harald Welte wrote:
Hi Holger,
On Thu, Jun 02, 2016 at 02:17:51PM +0200, Holger Freyther wrote:
I agree it is too many mails. I would like to see the patch (and updated patches) and comments to it. "Merged", "+2" with no human comment should probably not be here. Is this something you can deal with?
I _think_ so. But in the case of doubt, it could all be moved. I think if the list has 90% patches + reviews, it will be uninteresting for people outside the development team to subscribe to it, and users could feel intimidated to actually raise questions. At the same time, the project is too small to start separate -user and -devel mailing lists, either.
But let's see what other have to say about it.
I would be pretty much supporting a different list for all these automated emails. Or is there a way Gerrit can interact better with email by restoring the previous workflow? I'm feeling like a robot here ;). I follow the mailing list from time to time, whenver I have some spare time, to follow track of what others are working on. My feeling is that this is not helping me. Are you really getting a plus with this new tool? What is in your opinion what really improves in your workflow since you use Gerrit? I just have concerns that this may just kill the little community we have? Cheers, Pablo
Hi Pablo, On Thu, Jun 02, 2016 at 07:28:35PM +0200, Pablo Neira Ayuso wrote:
I would be pretty much supporting a different list for all these automated emails. Or is there a way Gerrit can interact better with email by restoring the previous workflow?
Same concerns here. So make that "+2" for all gerrit mails on separate list.
I follow the mailing list from time to time, whenver I have some spare time, to follow track of what others are working on. My feeling is that this is not helping me.
indeed, that was triggering my initial mail on this thread.
Are you really getting a plus with this new tool? What is in your opinion what really improves in your workflow since you use Gerrit?
I was very skeptical in the beginning, but from the maintainer point of view it is actually extremely useful. So I would recommend you give it a try from the point of "let's keep track of patches from various contributors, review them, provide feedback and eventually merge them" point of view. Comparing it to patchwork feels like comparing w3m to firefox ;) Some plus points: * you can immediately and automatically see who has reviewed and voted on each change (as opposed to manually collected "Acked-by" or the like) * when subsequent versions of a patch are submitted, you can easily see the diff between the previous (or any previous) version and the current version, with change requests (comments) interspersed into the diff, so you can see directly if your requests have been incorporated in the later version * all the review from all people is gathered in context of the particular code line / code lines, rather than spread over multiple diferent mails (one per reviwer) in an e-mail thread. * changes run through jenkins (build test, make check, make distcheck, or whatever tests you have there) automatically and are not eligible for merge if they cause such failures. This avoids merging patches only to discover immediately afterwards that they don't build or don't pass So I would really love to keep the above benefits.
I just have concerns that this may just kill the little community we have?
The many mails to the regular mailing lits: Yes, I really see the danger of this. But once those are a be on a separate list, that aspect doesn't matter anymore. Yes, every submitter needs to do some configuration before sending in a patch. But then, we're not the only software project that uses gerrit, so it's not an unusually high barrier. And then, the number of contributors is relatively small, so we can help them with the setup, if needed. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
FYI, we have just switched the gerrit e-mail notifications from this list to a new gerrit-log@lists.osmocom.org mailing list, which can be found at https://lists.osmocom.org/mailman/listinfo/gerrit-log So if you want tho subscribe to the notifications, feel free to subscribe to that separate list. If not, simply stay on the project lists (openbsc@lists.osmocom.org, osmo-net-gprs@lists.osmocom.org) and you will not see any such auto-generated mails anymore. Sorry for any inconvenience caused. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (5)
-
Harald Welte -
Holger Freyther -
Max -
Neels Hofmeyr -
Pablo Neira Ayuso