From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C784F1F4C0 for ; Fri, 25 Oct 2019 00:43:20 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=Jb2+U14Ij1sIk9AuofmaHBJDhq8cqbmizndr/FokRrf 0j9H6qGnvNePvFYJLDIwW93fGCsZmShXvvpaWFKOYb0emGjT7iKb86sEolw5VCnN LnoxH/pRk4GY1yaB/Rqr6DzrKlMktN0YdUZYtcmjUqJ87zb9ZJaG2OoAWToWMNi4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-type:content-transfer-encoding; s=default; bh=9WLWLAmQccPepNA19G10AsyAej0=; b=TAtWN3W2LTqc/pOf+ Epey4LavqBWaJo+vu8jSBhTDohdzmSDiGZHjimVrw1lxJb20qM3G3fB6mopy0LqP mFTWEd0MNXjRk48k1fjqRNDdftYYFb43+pFGL3Y1f/uO5Yrqz7Pj4O1e25i1hGKI RKZ+VHEOna5icEnA9g5m9FAHjo= Received: (qmail 36164 invoked by alias); 25 Oct 2019 00:43:18 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 36156 invoked by uid 89); 25 Oct 2019 00:43:17 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571964194; 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=CAwST6egNRYlr0MJBaNtg119vU+t4yQRMI2A6XKqcZU=; b=GJyEWRPOUOEKsBAXSpT53xyM1TCqGUR2NfMX7Me2AEShQBvWN3qZrADnz7tc/svyK/qNEa +IBVoGH8LgWCEO6NpgC7tzzj2+7707DG94feQZvTGKUEW7bu5r10Zu9hb51ic2JzCHvPte oz+44gPJtHMGeNAYOa5Pye2GOuOzmPU= Message-ID: <580baf4ff0699a1eed12c2ea48f2162db639ad1c.camel@redhat.com> Subject: Re: Setup non-pushing gerrit instance for glibc. From: Ian Kent To: Joseph Myers , Carlos O'Donell Cc: libc-alpha Date: Fri, 25 Oct 2019 08:43:04 +0800 In-Reply-To: References: <2e93ece9-386b-c587-9355-33a4695a3f02@redhat.com> User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2019-10-24 at 21:41 +0000, Joseph Myers wrote: > On Thu, 24 Oct 2019, Carlos O'Donell wrote: >=20 > > * Try to setup email based code review in gerrit. > > - Currently email is outbound only. >=20 > Observations on teething troubles with the initial setup: >=20 > 1. What's the status of fixing the problem with insufficient diff > context=20 > in emails when comments relate to particular parts of the diff? They > need=20 > to quote the relevant amount of context (typically at least the whole > diff=20 > hunk, including the hunk header showing the changed function name) > rather=20 > than just one line and a reference to an external URL. It's > important for=20 > messages with reviews to be meaningful in themselves without > depending on=20 > external links. This is a longstanding problem (it was obvious in > some=20 > experiments some people did with proposing GCC patches with > Rietveld,=20 > gerrit's predecessor, several years ago). Someone in the GDB > discussions=20 > mentioned a prototype patch to add some context to the emails, so > maybe we=20 > could use that patch. >=20 > 2. Could text comments in emails from gerrit be properly wrapped? =20 > Messages such as=20 > are hard > to=20 > read in the list archives because of very long lines. (Of course, > diff=20 > context / quoted source lines should not be wrapped.) >=20 > 3. Could we document (on the wiki, I suppose) the process for setting > up=20 > git remotes if you want a git repository to get local copies of all=20 > versions of all changes proposed this way? My understanding is > gerrit=20 > makes those available as refs named in some particular way, so adding > a=20 > remote with appropriate fetch config should work, but the particular=20 > recipe ought to be documented. >=20 > 4. Could we document how to get and keep up to date a complete local > copy=20 > of all the glibc review data in gerrit (comments etc.) using whatever > APIs=20 > are available? Again, I think the relevant APIs already exist, but > how to=20 > use them for glibc ought to be documented (this is especially the > case for=20 > a service like this that's experimental, and thus might go away in=20 > future). >=20 > 5. It would also be useful to have documentation for how someone > should=20 > make a patch series appear appropriately in gerrit if they want to > propose=20 > a series that way. That means the emails for a patch series should=20 > include 1/N, 2/N etc. in their subjects (with a 0/N cover letter as=20 > appropriate). I haven't spent much time with Gerrit but the time I have spent I've found myself thinking Gerrit is designed with the assumption that submissions are "one" patch. I found handling a patch series (which I almost always have when doing changes) rather painful! >=20 > 6. Lower priority, but note there are certain kinds of changes > involving=20 > huge diffs (e.g. to generated files) that thus *would* need a message > size=20 > limit and pointing to a URL for the diffs in that case, for it to be=20 > possible to handle such changes through gerrit. (When sending email=20 > manually for such a change one can always omit the 50 MB of diffs to=20 > generated files, but as I understand it part of the point of such a > patch=20 > review system is that the system seems the exact change proposed to > be=20 > committed, complete with generated files, so enabling automated > testing of=20 > patch proposals if desired.) >=20