From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23715 invoked by alias); 20 Oct 2019 22:25:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 23706 invoked by uid 89); 20 Oct 2019 22:25:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.3.1 spammy=Sunday, sunday, decides, whoever X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 20 Oct 2019 22:24:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571610296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RkkMRczj2RVt4nydJAbAVsfK/MfzXRz1EMCWpZ1WDEU=; b=EuCUS11K19kXbuya118T8sxOHEbrOYpsIS2QvII0FQxEnI/P6IrwH8dvuPm+kE4JLHwaQw E7Hj8xPBdpozAyAwIf6Q9D/+CjJYVNgRkBZk3M9KXIDjRIwbQ7ra9wwrRgsS3IYyVFNaFK GUwQ5DJni9Oco4RcBnx19lJUaF6/Yhc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-171-YWdiwxieOISq-TVUz-k5pg-1; Sun, 20 Oct 2019 18:24:53 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DE813800D41; Sun, 20 Oct 2019 22:24:52 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id B07895D9D6; Sun, 20 Oct 2019 22:24:52 +0000 (UTC) From: Sergio Durigan Junior To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: some thoughts on gerrit References: <877e4z8ovc.fsf@tromey.com> Date: Sun, 20 Oct 2019 22:25:00 -0000 In-Reply-To: <877e4z8ovc.fsf@tromey.com> (Tom Tromey's message of "Sun, 20 Oct 2019 08:37:11 -0600") Message-ID: <87eez7f423.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00703.txt.bz2 On Sunday, October 20 2019, Tom Tromey wrote: > After using gerrit for gdb for just this past week, I have mixed > feelings, which I thought I'd share. Thanks for your email, Tom. > The upside is pretty good -- basically what I was hoping for when we > discussed this topic at Cauldron. > > The major benefits is that it's easy to see the status of patches. > > A benefit I didn't predict is that it's a bit simpler to submit patches. > In particular, my personal email host doesn't like it if I send log > series, so I have to remember to throttle when using send-email -- but > with gerrit that's a non-issue, because it is just a push. I haven't submitted any real patches yet, but for me this problem doesn't apply, so I can't comment on it. My workflow is likely to stay the same: git-new-workdir, hack, submit (either via gerrit or git send-email), push. > So far the major downsides are related to patch series. > > [[[ > First, as an aside, my most recent patch series does show up here: > > https://sourceware.org/ml/gdb-patches/2019-10/authors.html > > (Search for "RAII class" under the name "Tom Tromey (Code Review)") > > ...but it somehow doesn't show up here: > > https://sourceware.org/ml/gdb-patches/2019-10/threads.html > ]]] > > > Anyway, with series we are missing two things that email had: namely, > the cover letter, and threading. I saw your patch series yesterday night, and I had the exact same thought as you. Cover letter and threading... > The cover letter is often a good guide to what is going on in the > series. See for example: > > https://sourceware.org/ml/gdb-patches/2019-10/msg00590.html > > It seems a shame to lose this. I absolutely agree. > One counter-argument about the cover letter I thought of is that, > because it doesn't end up in the history, maybe the lack of it will > force us to make each commit message even clearer. And, we should do > that ... it's just that the roadmap is handy when reviewing. I see your point, but I still think a cover letter serves a different purpose than the commit messages. A cover letter introduces the big picture, and it is often a good place for reviewers to make generic comments about the overall implementation. > I wonder if there'd be a way to make "git review" prompt for a cover > letter and attach it somewhere as a comment. That could work, I guess, but it would still be a bit cumbersome. I found this on gerrit's bugzilla: https://bugs.chromium.org/p/gerrit/issues/detail?id=3D924 It seems like there was a request, but it was closed very recently due to inactivity. Perhaps we could try pushing a bit more... > Lack of threading means it is hard to see how patches relate when > reading in email. Maybe this can be fixed in gerrit? I don't know, but I'm hoping that when I configure gerrit to accept emails, this will be "magically" fixed. The reason is because if gerrit accepts emails, it is also the only "entity" to reply to its own messages, which may be easier for gerrit to keep track of Message-Id's and In-Reply-To. I should have an update about this tomorrow, and we can see what happens. > I wonder a little if a sufficiently configured patchworks would be a > better fit for gdb. > > The major problem with the current patchworks is that it doesn't > automatically remove patches when they are checked in. However, a newer > version of patchworks can do this, especially if we augment it with a > commit hook to add a UUID to the commit message (which we've already > accepted for gerrit...). It seems easy to set this up. > > Another drawback of patchworks is that reviews aren't done online -- you > still use email. This doesn't bother me, but maybe it's an important > consideration for others. The way I see it, I think the top patch reviewers should come together and decide what works best for them. Maybe it is patchwork, maybe it's something else. I know that I would not use patchwork that much, even if it is configure to automatic remove patches when they're pushed, but in this case I think patchwork's purpose would be only to serve as a dashboard for whoever is reviewing the patches. > I'm not saying we should definitely switch -- just that I've noticed > some drawbacks to gerrit as compared to email, and I am wondering if we > can somehow preserve more of the good things. Sure thing. I'd like to see if the threading problem gets fixed when gerrit starts accepting emails, at least. Other than that, I personally don't have a preference, and I would not feel bad if the community decides to drop gerrit. Cheers, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/