unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Gabriel F. T. Gomes" <gabriel@inconstante.net.br>
To: Carlos O'Donell <carlos@redhat.com>
Cc: libc-alpha <libc-alpha@sourceware.org>,
	Sergio Durigan Junior <sergiodj@redhat.com>
Subject: Re: Setup non-pushing gerrit instance for glibc.
Date: Tue, 12 Nov 2019 15:53:03 -0300	[thread overview]
Message-ID: <20191112155303.2215a667@tereshkova.br.ibm.com> (raw)
In-Reply-To: <2e93ece9-386b-c587-9355-33a4695a3f02@redhat.com>

Hi, community,

I finally used gerrit today.  Afterwards, I re-read this thread and here
are my impressions and questions...

First of all, thanks for doing this.  :)

(CC'ing Sergio, because I don't know if he follows the list and I have a
question for him)

1. On Reviewed-by statements,

On Tue, 12 Nov 2019, Florian Weimer (Code Review) wrote:
>
>(I'm not sure if we can keep up the practice of adding Reviewed-By: lines
>with Gerrit, because doing so creates a new patch version that needs
>review.)

Florian noticed [1] that Reviewed-by statements might break our use of
gerrit, because changing the commit message creates a new version of the
patch.  Carlos mentioned that having the statements is useful for his
metrics (I also like these fields, even though I don't use them as
professionally).

If we are going to make gerrit push automatically one day, could we make
it add the Reviewed-by statement automatically (based on the Reviewers
field) when it pushes the change?  Maybe it doesn't even need to create a
new version of the patch with the new commit message (although it would be
nice if it could create some sort of link between the patch that actually
gets commit and the patch displayed in the web interface (the same that is
sent to the mailing list)).

If that is possible, then the patch author (or even the reviewers) won't
need to change the commit message *during patch review*, which will avoid
the creation of the new patch version.

[1] https://sourceware.org/ml/libc-alpha/2019-11/msg00404.html

2. On in-reply-to fields,

Also in the same review [1], I noticed that the emails sent to the mailing
list are threaded in a weird way.  Everything seems to be sent in-reply-to
the first email of the thread, similar to bugzilla's behavior.

That is only a bit weird when it comes to patch versions, because the
subject lines contain a [review vN] tag, making it somewhat easier
(although not perfect) to distinguish which messages belong to each
version.  It will maybe become a bit more weird if a long discussion
happens in a sub-thread.

3. On quote selection freedom,

When writing reviews by email, I like to select the precise amount of
quotes (stitching different quotes together, and snipping unimportant
parts) that I judge relevant for the conversation.  This is, obviously,
a subjective judgment and I don't expect any tool to be able to do the
same ever (famous last words?).  My point here is, I didn't find a way to
do that (adjust the amount of quote and snipping) on the web interface.

On Fri, 08 Nov 2019, Simon Marchi wrote:
>
>So please try to use "Quote" instead of "Reply" and quote
>the relevant portion of what you are replying to (just like you would by
>email), so that it appears in the notification email.

Simon mentioned [2] a "Quote" (button?).  Maybe that is what I wanted and
couldn't find.

Like others in the community, I think I prefer using email, which gives me
freedom to select the amount of quoting and snipping I want, so maybe this
will never be a problem to anyone.

[2] https://sourceware.org/ml/libc-alpha/2019-11/msg00306.html

4. On the "patches go missing" problem,

On Sun, 27 Oct 2019, Sergio Durigan Junior wrote:
>
>When the GDB community decided to give gerrit a try, the main problem it
>was looking to solve was the "patches go missing" issue.  Basically, we
>have a lot of patches being sent to the project and not so many
>reviewers, so it's not uncommon for a patch to get "buried" waiting for
>a review, and if the author doesn't ping it, it gets lost.  With gerrit,
>you can get a pretty good view of all the patches that were submitted so
>far, and you can always check if a patch is too old or if it's been too
>long since the last interaction on it.

Can you (GDB community) already tell if gerrit actually helped with those
patches that went missing, or is it to soon?  While I understand that
gerrit has the potential to help with that, I also get the impression that
patches will still pile up, but on the web interface, instead of on the
mailing list.  I get this impression because our patchwork instance has
piles of patches (btw, this is not an inquisitorial kind of question - my
heart is still open for the new tool - I just want to know if you think
gerrit is helping).

  parent reply	other threads:[~2019-11-12 18:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 19:39 Setup non-pushing gerrit instance for glibc Carlos O'Donell
2019-10-24 21:41 ` Joseph Myers
2019-10-25  0:43   ` Ian Kent
2019-10-25  1:16     ` Jonathan Nieder
2019-10-25 10:21       ` Ian Kent
2019-10-25  1:02   ` Carlos O'Donell
2019-10-25  2:04     ` Sergio Durigan Junior
2019-10-25  3:14       ` Simon Marchi
2019-10-25  4:10         ` Simon Marchi
2019-10-25 14:48         ` Joseph Myers
2019-10-25 15:48           ` Simon Marchi
2019-10-25 16:10             ` Joseph Myers
2019-10-25 16:28               ` Simon Marchi
2019-10-25  1:25   ` Jonathan Nieder
2019-10-25 14:09 ` Florian Weimer
2019-10-25 15:18 ` Joseph Myers
2019-10-25 17:00   ` Sergio Durigan Junior
2019-10-25 20:33     ` Joseph Myers
2019-10-25 21:06       ` Sergio Durigan Junior
2019-10-25 21:13         ` Joseph Myers
2019-10-27 22:12           ` Sergio Durigan Junior
2019-10-28 17:58             ` Joseph Myers
2019-10-28 19:17               ` Jonathan Nieder
2019-10-28 22:59                 ` Joseph Myers
2019-10-29  1:21                   ` Sergio Durigan Junior
2019-10-25 22:03       ` Jonathan Nieder
2019-10-26 13:53         ` Carlos O'Donell
2019-10-30 18:25 ` Szabolcs Nagy
2019-11-12 18:53 ` Gabriel F. T. Gomes [this message]
2019-11-12 19:21   ` Carlos O'Donell
2019-11-12 19:59     ` Florian Weimer
2019-11-12 20:02       ` Jonathan Nieder
2019-11-12 21:10     ` Gabriel F. T. Gomes
2019-11-12 21:13       ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191112155303.2215a667@tereshkova.br.ibm.com \
    --to=gabriel@inconstante.net.br \
    --cc=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).