From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 1C8703858D20; Wed, 1 May 2024 19:38:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C8703858D20 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 1C8703858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::635 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714592320; cv=none; b=ZHeE8WETzhoa+CU8gmoEI41CgP7VpSketRkVof5Jc3Tu1/w9WEor2qULpjZ2b6sW+HdIWyfGaLbaVaeFgPc46z67dOoQWlA6GPm/p0KGIiwvRgpekwpdhEuZ352YtkKAnKPc3ElpZIlwd+iry8huFPoSiAF9MSLnT9CkfJWpZzQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714592320; c=relaxed/simple; bh=9Fs1NNk5X1gCvrunwLdh78Ems+aCYnkh/JIkqip3F9U=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Yc6/tF/LmmM78Npt8pMMLsP9xKS3uW2plj324zzBNwUR5Qwqua4HbCZ6VbcipCPoJgjcbYrKUPsivBM9NCcBYTHjaOHDSNzFiPqLaHI3h9ZHwQP4oywQofeyteaDA3q70RCESvN8eQc04BQ+jyOscy7/L6OtKJX+HhizOx+fD9w= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a55b93f5540so978179466b.1; Wed, 01 May 2024 12:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714592318; x=1715197118; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dXaXXuI3W6uxISVHl6Eq7CkwXoOhqrK0oU6j2l3ho6E=; b=Q7uNPnvz90s5bhCuAqhM6ad31SD5j/5Su3oVwgPpmjWdMC0DKSygvu/TsAcSx92R+8 EcGYOG6hEmQUFLMmpeVYR64p8AoVEI2zTxQry2C3EEcXv/LSjD15wiDHdJLk35vhXB34 +jiBfdw5U7+VH/reZr2/vLp+fzRGMRTu0uHIvyts/VPe18vD3K1O1ATrJq8ToTG+zjZT tOkPRRAtLEFdkTQXSae23CVzXvM1vftQipbqwmciNIomLIsJNT1rqNnUZbgRFkCuPTFe 9eq7TgKTKawUWdEB+LWzP++IXcWoUMeyX3oLeriXrVo+r44NuOPvVVuCbWuV1J/mqhwo VXng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714592318; x=1715197118; h=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=dXaXXuI3W6uxISVHl6Eq7CkwXoOhqrK0oU6j2l3ho6E=; b=F+Ml9oes+U7rWxeWRw/CImaznOIijtYekt/uSNe7z11Hk1jR8icQ8lTYjjInOsZp4Q dusZNGiKyiLLea9GbU4qLHGyLorvFqDCbkXBW/QHOMJgxf8wL0asvitOwhGeiEnTN202 RhrEgD97gB2elkHB+/INoyy3kmQOnkrcguM8HZbpBBo89DnwZyhDgDRKCTzTSjvjCGYL MaMFgdtfgUQZusUJPUvhIKba9mjjfd6r5nn7IDwBqXeMSvCnOIwEAwih24lr66A8AuG6 sR9TUSkrvjD7L6ep6Vj1zg2nPdq+C8U6tg5dsyK+4lo0LK5H8TRQbd1lMBdz02T+JYM7 jYxQ== X-Forwarded-Encrypted: i=1; AJvYcCWxKy5qTQ3F6o1bCbizNooBG1hIaoppyta2aTwodDYAnPRiGGq7++NTnrqQbX5eIO7WDneSo3caoeeKr0jAVJqd8ZUI+83+5JnTMs24b9ycgQtBg3a+ybVv6Y9Kedgk8GbUIPvNbcdtV6wSSHAQwdc+eXNrmxLeLpQFaX1Ju8pHN1SNGb5J080dVutIwrYxZYU= X-Gm-Message-State: AOJu0YxHqmd7NoJivnSjyaWCGNt3VLjyq32x7u60c1eCOIsLRbcegYfB qlhVIYNpGDZYuqbLOWMH0V7Az8efPJFX/xVPvCTJqPNESXO38oAof5eknqqU/gl7uYDwSwSOsxz LjdzsXGRxKha6eZv1GVSjQpMl5vU= X-Google-Smtp-Source: AGHT+IGMYSrgwB+Zx1nGFrhcczrPeD8uznBgMOv25ciO9P5eCKvtgjrUH5nYt7hxEYUIFi6ajCpR2YJsT5Ls8hi1vgI= X-Received: by 2002:a17:906:3a82:b0:a58:832d:c3e8 with SMTP id y2-20020a1709063a8200b00a58832dc3e8mr2338532ejd.58.1714592317581; Wed, 01 May 2024 12:38:37 -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> In-Reply-To: <0347e05a-94c6-4ecc-aa8f-cc90358a813d@gmail.com> From: Jonathan Wakely Date: Wed, 1 May 2024 20:38:26 +0100 Message-ID: Subject: Re: Updated Sourceware infrastructure plans To: Jeff Law Cc: Tom Tromey , 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 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=ham 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, 1 May 2024 at 20:19, Jeff Law via Gcc 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. If patches sent by email exactly match what's committed, then the update_gcc_pw.sh script that I run will correctly update patchwork to say they're committed. I tend to only bother running that once a week, because it misses so many and so is of limited use. If we are now supposed to send generated files in the patches, and we discourage people from committing something close-but-not-identical to what they sent by email, then the script will do a better job of updating patchwork, and then we should look at running it automatically (not just when I think to run it manually). I think there's still an issue where a patch has been superseded by a v2 which has been committed. I don't think patchwork does a good job of noticing that the v1 patch is no longer relevant, so somebody still has to manually update those ones. So overall, I agree that patchwork isn't the answer. It requires too much manual housekeeping, and that's a huge task with the volume of patches that GCC has. > > 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. > > jeff