From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) by sourceware.org (Postfix) with ESMTPS id 91E39385773C for ; Tue, 18 Jul 2023 13:24:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 91E39385773C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 08059141306; Tue, 18 Jul 2023 13:24:27 +0000 (UTC) Received: from pdx1-sub0-mail-a286.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E16FB141D83; Tue, 18 Jul 2023 13:24:25 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1689686666; a=rsa-sha256; cv=none; b=OtNtbXM75X10Hydopfvnq6QuRQRc4GjhwVPCaOJ5pVdFsXOluTc6M0PsTGFqpsbhJ6re6X WBolTRgL1+Vqwe9ML5FvNw2LZtPDhIft4sEsNhAi/vhzxE6Ka/lOE1/3tjper+DCt8Tcsv ouQWAPtM/FGfEinHl6QuoGMthI/dU0DBaxByALLC0T+ZDvdxadCogGW2EK7bNfYs4vc+CJ 3zeyXH/D91W3YLTkf6EY568KzxRqb/CnLUQa2zu+3PZKJ562EjORh5AUI3mC+Mvsm/OT8/ 45PQYPZBK7tR+PiRvEkQMI0OgGJZn0vv4rkYW9upwWx4b4ipboHWZClx8uzhbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1689686666; 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:dkim-signature; bh=xdkQz2gVkLoRdTuEiuzAG1Rrrxm8bm480PEs6uJ5qt8=; b=dCLrJ0wEYODRUMI6CheStZ2iy+AmDAEuNbk1SbcdElvQdcbEe5W+e51md6t85yJ4kz5mpP M4CrpGIbm6mqBKcNhbPpRUyKmtkckqejMOASqvwK7hnC/2jwrS8J+JIdXQ7drrRyZDG6ql wIuwotLUyMgmvlhWxqBez1fuPnIfw+DcWzLYqdS0pOA5MXukh2b0xC4XUcWp+rkJur6FSL L1248q56bXIub/G4/mVI0cRkp3J8PnjBNsdlfWCM/s1s/VGJ10ko7NK7odG4i8rlPco8AD Z4jrsublo33WrSbB7z9l/PQcFiXlPyQFRSHVrz7qGikLY8hCUIK6Vueix/ZVeQ== ARC-Authentication-Results: i=1; rspamd-7d9c4d5c9b-rxsvm; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Descriptive-Print: 3b46f6635ed4648e_1689686666266_880615905 X-MC-Loop-Signature: 1689686666266:2382029015 X-MC-Ingress-Time: 1689686666266 Received: from pdx1-sub0-mail-a286.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.217.233 (trex/6.9.1); Tue, 18 Jul 2023 13:24:26 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-09-174-91-45-44.dsl.bell.ca [174.91.45.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a286.dreamhost.com (Postfix) with ESMTPSA id 4R506J62hlzn3; Tue, 18 Jul 2023 06:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1689686665; bh=xdkQz2gVkLoRdTuEiuzAG1Rrrxm8bm480PEs6uJ5qt8=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=GIGCkhqKV/lpOHACZT0hQRivzVbRnXi/KQywlWe/QjPiywWt/Ruui8T0KTz21UYfU Qybx/tmldyyL8kziHbiIJuddNuxLhkTKkU96J9enUZsUMO9mH93vKboQv7u5ZZBBjI XeWKUZ/rSI2D4S9WhW6NVLmWwVPdsN8A/Youc2xUdNLuz5nJqlx8TL9cLsW3EIq69w ldnUWBbD54HKj8JlJT26plW09Ikh+i26who2kQOFl/KbRNuN94/ibOGGqRC5hjlFWB EqgOa7YB2Kdlbv23iYGI4zZQoQWn8n77ZyIXMboLqIvahM4/Gp2A9zYDSyQn5urDTV A+s4vQyaz2S5Q== Message-ID: <0f4ada35-3986-4590-e101-23597b684e43@gotplt.org> Date: Tue, 18 Jul 2023 09:24:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: Core Toolchain Infrastructure - Services for glibc Content-Language: en-US To: Jeff Law , Jakub Jelinek Cc: Konstantin Ryabitsev , Florian Weimer , Carlos O'Donell via Libc-alpha , Carlos O'Donell , Joseph Myers , "Ryan S. Arnold" , Paul Eggert , Maxim Kuvyrkov , Andreas Schwab References: <45e98807-908f-0968-b6fe-5dbb0af265b1@redhat.com> <87ttu6oh9j.fsf@oldenburg.str.redhat.com> <20230714-card-radium-prow-27d2f1@meerkat> <2b743481-4dc3-07a1-fe65-a32a9d1df09a@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3027.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 2023-07-18 09:19, Jeff Law wrote: > > > On 7/18/23 06:26, Jakub Jelinek via Libc-alpha wrote: >> On Tue, Jul 18, 2023 at 07:47:37AM -0400, Siddhesh Poyarekar wrote: >>> On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote: >>>>> Can we keep using the AdaCore hooks?  Or would they have to run on the >>>>> side somehow?  Who is going to implement changes to the AdaCore >>>>> scripts? >>>> >>>> This is the main point of contemplation -- we do not currently >>>> support custom >>>> hooks on the server side: >>>> >>>> - they tend to significantly slow down pushes >>>> - they run extensive codebases with the same permissions as the >>>> owner of the >>>>     repositories, significantly increasing security risks >>>> >>>> Our recommendation was to move all CI tasks to a system that is >>>> better suited >>>> for it. For example, CI can run on a patchwork system and the >>>> pre-commit hook >>>> can then check that each commit matches a patchwork entry that >>>> passed CI. >>> >>> This would mean porting AdaCore hooks to a patchwork trybot.  This >>> would be >>> an acceptable solution for glibc, but I'm not sure how useful this >>> would be >>> on the whole since gcc doesn't use patchwork as extensively at the >>> moment. >>> Also, we need to figure out who's going to do this. >> >> It is definitely not acceptable for gcc, we strongly rely on server side >> pre-commit hooks for various different tasks. > BUt the key (I think) is they're not trybot/CI style hooks.  They're > doing things like wiring up commits to the lists/bugzilla, verifying > ChangeLog bits and the like. > > I think the point is that any hooks need serious thought about what they > do and the attack surface they represent.  So for example firing off > pre-commit CI, not advisable.  Having a hook that queries another system > for the state of pre-commit CI may be reasonable. > > I would think that verifying ChangeLog format might fall into the > reasonable space.  Not sure about lists/bz integration hooks. Yeah, putting ChangeLog format verification into a patchwork bot won't work anyway since patchwork ignores the git commit message when identifying patches. Sid