From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 9E6AA3858D34; Thu, 2 May 2024 06:47:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E6AA3858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9E6AA3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714632464; cv=none; b=Oo15EMtAW9b2V1IG3Az6TNrkIDHY5WkCa91/aI9UdZZTY7hSpA+joYN4SkT1qUBROevigRnE4x8c5MMY10C/e3wK+4R7wM0FXC+qVcTeYXi0ZALLyw8m55k5hIrbnP8Z6hhaNkPIV0gj5bSrkmFucJUcK6nZHio+YOba55If1dk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714632464; c=relaxed/simple; bh=aV9QGjaYA+GwrXLyF+iLB2Bg3/xd39ufZB+k52zfX9M=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=JY1993fwt24P8F4bm+XOXdJi4mC+HqSRt1zN9T/arg3eOV3P2ImrAbk9k+9X7rd4b2H1jahBMyF5eOclL1ozCRqAGYg9R3QSYBJKnWmOmTn/kw56flq7dWOG2RPN4bxVI/42WXMDO6jMYwRutsAaepHhazowvKJGvXudE1MGQdw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-51f29e80800so290690e87.2; Wed, 01 May 2024 23:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714632460; x=1715237260; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JZ5XzoWyGXoC6+hEhV9LAqQsCNblYZ09v6D9OFHxX+s=; b=Q/kY46jZVnK42gXXam+roUUOyJnJ1e+FIReOULRfRWbfbzUIjT5Bw40gNX5r82Vlo5 C3rmdbzXdx19s7PUxVW88ZT+JfcdjqQ8Iy2/VkcRW5tllYZpUwjx9sOj1fXDV1Uj83gB cTX8dMx3AU+s60PGkn+zMLmxCcnElA4imAOFjNpGiHpnPVVGWYRl3In0m5khOrtdMNTc wdk5UHTLifbS+jUX+Lk6P3yoEKyqQb+BLOw3uvJKpZpf7gjylB3PiM04ayLLAg7nffy2 hVRiNBhpRmcIFq75NOas8JQEy4y13OXKUVBDxhzEDUGOBVLP18VnjjSEdAHPS9zVASKk KDhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714632460; x=1715237260; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JZ5XzoWyGXoC6+hEhV9LAqQsCNblYZ09v6D9OFHxX+s=; b=FDUBf396PUoBmxKyU3gcHn9gZj8S8u45R4XMnetNRKKObJQE1znoydOUjrDsa7OcvF fkTB83ygJW1WAqWVhctLZfkq49SdIB9fIdOIMFhro4AJDZMN1n5u9GViCmSPRf7CIsvW Yf2bidRp4w1vkOsFcTrqLiU39fsmF4yjbgRY9rJFh9FOWOrNXf3UUCRczZMtVQS35pCn zPb8ja441/jASv02/mhu0YHwgRWeWcomIxXP/qDz0fqUwSsdWwTfSbQOV5Wz/7dB1w2G 3JJu/FD+YJv3gXA/MCG5m+RWWlsGTc761a1oa/mgEnBDcG+v45qdoQCP8iqz/0p2q1Zp b8dA== X-Forwarded-Encrypted: i=1; AJvYcCWVy6UorDWli/znjGgZexhgy5vI9Dcn8DR77Oiyemc3ZT0VGuO5g6us+fIRnNdlE9JS70RTVjWsqVOAcfyJUc5/O9enrqyvcS8oAhWN6JFs3ZtTC9F68Dbm4Js+gVA8x0TKaMJc8B/k5ZFg3qrUxYc0b35705x8vzymvcPw7go8GR0umvTvvjWlB8VecQAyGTQ= X-Gm-Message-State: AOJu0Yyp85nKstf8gI0p5WEbWLti4sELWr7/243GOZYc60F+jXSUHaN0 1rWoVUq75Os8ggkKDL1bQqnOV4YahfS7BUsaz5RdX8m7yTKUZnyn2JP8fy2Jfv5KdB+m1ZtQ7U8 +RCpNLPXSC1MtwhIXK/K4lcdZtX4= X-Google-Smtp-Source: AGHT+IEmVuGc5i8alE/ffKRASHb4sF7o1lrYfH1gZ2Eifx3dmAl3NKjaz7HtfAJQD8wT8zO2xIZvCczTehc6qom6jF0= X-Received: by 2002:a19:8c58:0:b0:51e:eeb1:f24b with SMTP id i24-20020a198c58000000b0051eeeb1f24bmr564620lfj.34.1714632459756; Wed, 01 May 2024 23:47:39 -0700 (PDT) MIME-Version: 1.0 References: <20240417232725.GC25080@gnu.wildebeest.org> <20240418173726.GD9069@redhat.com> <87v849qudy.fsf@tromey.com> <87wmooep76.fsf@tromey.com> <0347e05a-94c6-4ecc-aa8f-cc90358a813d@gmail.com> <0d0af1d9-21f8-4c60-ad4c-cd82c0c0cabb@redhat.com> <9580dbf5-5357-404c-b6f2-5e21fd369d3e@gmail.com> In-Reply-To: <9580dbf5-5357-404c-b6f2-5e21fd369d3e@gmail.com> From: Richard Biener Date: Thu, 2 May 2024 08:47:28 +0200 Message-ID: Subject: Re: Updated Sourceware infrastructure plans To: Jeff Law Cc: Jason Merrill , "Frank Ch. Eigler" , Overseers mailing list , Mark Wielaard , Joseph Myers , gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org, Tom Tromey Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, May 1, 2024 at 11:41=E2=80=AFPM Jeff Law via Gcc = wrote: > > > > On 5/1/24 2:04 PM, Jason Merrill wrote: > > On 5/1/24 12:15, Jeff Law wrote: > >> > >> > >> On 4/22/24 9:24 PM, Tom Tromey wrote: > >>> Jason> Someone mentioned earlier that gerrit was previously tried > >>> Jason> unsuccessfully. > >>> > >>> We tried it and gdb and then abandoned it. We tried to integrate it > >>> into the traditional gdb development style, having it send email to > >>> gdb-patches. I found these somewhat hard to read and in the end we > >>> agreed not to use it. > >>> > >>> I've come around again to thinking we should probably abandon email > >>> instead. For me the main benefit is that gerrit has patch tracking, > >>> unlike our current system, where losing patches is fairly routine. > >>> > >>> Jason> I think this is a common pattern in GCC at least: someone has = an > >>> Jason> idea for a workflow improvement, and gets it working, but it > >>> Jason> isn't widely adopted. > >>> > >>> It essentially has to be mandated, IMO. > >>> > >>> For GCC this seems somewhat harder since the community is larger, so > >>> there's more people to convince. > >> I tend to think it's the principal reviewers that will drive this. If > >> several of the key folks indicated they were going to use system XYZ, > >> whatever it is, that would drive everyone to that system. > >> > >> We're currently using patchwork to track patches tagged with RISC-V. > >> We don't do much review with patchwork. In that model patchwork > >> ultimately just adds overhead as I'm constantly trying to figure out > >> what patches have been integrated vs what are still outstanding. > >> > >> Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs which > >> we use heavily internally. But boy I want to get away from email and > >> to a pull request kind of flow. > > > > Do you (or others) have any thoughts about GitLab FOSS? > I would assume its basically the same as gitlab, except with any > proprietary removed and that new features land in the enterprise version > first and presumably migrate to the FOSS version over time. > > > What works well? If you've wired up some CI bits, it's is extremely > useful to test an under development patch. Develop, push a branch, > raise an MR. At that point the CI system kicks in. Subsequent pushes > to the branch trigger fresh CI runs. This aspect I really like and if > you were to see internal flows, you'd see dev branches churning as a > patch gets iterated on. It also has features like "when this passes CI, > automatically commit it", which we often use on the final patch > iteration if there was a nit of some kind. > > > > > What doesn't? Finding things in gitlab is *awful*. Now we're just > talking about one repo, so it may be more manageable in that regard. > And we're not talking about using it for bug tracking. As long as we > kept on top of the MR queue, maybe it would be feasible. > > So maybe I should soften my stance on gitlab. If we're not using it for > bug tracking and hosting many projects, then maybe its viable. > > I think the driving force will be whether or not folks like you, Richi > and others that do a ton of patch review would be more efficient in a > gui or not. I don't think I am, but maybe that would change if I did it > every day for decades like I did with email :-) We'd only know for sure if we try. But then I'm almost 100% sure that having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA I am using for "quick" patch review. It might be comparable to the review parts I do in the gmail UI or when I have to download attachments and cut&paste parts into the reply. It might be also more convenient for "queued" for review patches which just end up in New state in either inbox. But then would using gitlab or any similar service enforce the use of pull requests / forks for each change done or can I just continue to post patches and push them from the command-line for changes I can approve myself? Btw, for any forge like tool I'd even consider there'd be the requirement that _all_ functionality is also accessible via a documented (stable) API, aka there's command-line tooling available or at least possible to write. Richard. > jeff > >