16 May
2016
16 May
'16
10:41 a.m.
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#notif…
17 May
17 May
1:48 a.m.
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(a)sysmocom.de>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(a)xx.vu>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
18 May
18 May
9:31 a.m.
On 17 May 2016, at 01:48, Neels Hofmeyr
<nhofmeyr(a)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
17 May
17 May
10:01 a.m.
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#notif…
--
Max Suraev <msuraev(a)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
11:42 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
12:22 p.m.
On 17 May 2016, at 11:42, Harald Welte
<laforge(a)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:
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
> 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...
19 May
19 May
2:27 p.m.
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:
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
> 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
2 Jun
2 Jun
1:53 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2:17 p.m.
On 02 Jun 2016, at 13:53, Harald Welte
<laforge(a)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.
2:40 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:28 p.m.
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 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
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.
7:46 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
8:56 p.m.
FYI, we have just switched the gerrit e-mail notifications from this
list to a new gerrit-log(a)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(a)lists.osmocom.org, osmo-net-gprs(a)lists.osmocom.org) and
you will not see any such auto-generated mails anymore.
Sorry for any inconvenience caused.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2891
days inactive
2908
days old
12 comments
5 participants
participants (5)
-
Harald Welte -
Holger Freyther -
Max -
Neels Hofmeyr -
Pablo Neira Ayuso