From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4IhEB0a+7WaNmTEAWB0awg (envelope-from ) for ; Fri, 20 Sep 2024 14:26:14 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=wsQdtTTE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0F0B81E353; Fri, 20 Sep 2024 14:26:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-11.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id F329B1E05C for ; Fri, 20 Sep 2024 14:26:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6CEFD3858431 for ; Fri, 20 Sep 2024 18:26:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CEFD3858431 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1726856772; bh=TIHVTeCIEJViACcU6GCSr67eM8SH5QEtSY+gBj48AOI=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=wsQdtTTErEJLZ2FKMrdyku0o2lebD+KZpG/wxM20Ncv7sg27k1Rn5P434HCqwz4F3 kiKQvTZFc5x8ev41NQIFV2EJLaF0AeiBQkmLF4AHh7CAU0SAuo/b1InA0SgWqGfNP3 Puicr6nMYx2kH1jr3iWAbRhV+k/j8E+GLj5+hLrQ= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 466CD3858D29 for ; Fri, 20 Sep 2024 18:25:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 466CD3858D29 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 466CD3858D29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726856720; cv=none; b=Xjl7xuwzSnVgC3aWtjoEaxkzXOOjp5XRHEmX58n9tx4qXjhe5Ap7w5XmiQZ80bGvpZcPJcPlAA7JAsDXucbSItvP72Vl+geLkg8VRTeKkzLVeF6kVo3/G2aZ6OvKdDzOC02mkMLvYHSFwavMXaHTN0Jt12Cwn/1AdA8iEps5pAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726856720; c=relaxed/simple; bh=8xcQHhuqQX8UnbJDXydDUrOINV+G2xmcsb4lNvQLlOI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=kF9BlDGfzDuKfStS1Db/mxYlai3yydQPmdlBSOQOCLItqjZMPq2zXM847D06w8PpM/XT0HSCVTxkMzPBu2dcnhMC8WMdV5CLFtGL8sSQ/Gp0Oo8ZV1O1VhZTvufHy5sdgeSxU1s4b2X9jmZjGXwFkDLbtwFSjOgw/D749nUKYQs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-DiDZXcR6PXumqevmjyntig-1; Fri, 20 Sep 2024 14:25:15 -0400 X-MC-Unique: DiDZXcR6PXumqevmjyntig-1 Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2058ba8562fso44927925ad.3 for ; Fri, 20 Sep 2024 11:25:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726856715; x=1727461515; h=content-transfer-encoding:in-reply-to:organization:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TIHVTeCIEJViACcU6GCSr67eM8SH5QEtSY+gBj48AOI=; b=N9eqFIxSbhO17Gelbsdb3X71tupxBC0pv/T1ha7R0UPHJwCJfSQv18/K/cJza+ssaX 9SyexSCbCx8gMwttKV3c3mGkRTTi6I5ckRjlKdkT+w2bsG/YE0sjQ9AWKMJz+EnJd6kZ 7SGo5FsNjh6hTsmTLdop6mAuQYBZSm16qxn9R54PKFagmF8FO9fOdQjR1s+/7oL94uAF DCc239R3ceoXTGFsBhVYJy6vasY9MCBmKc9Acy4K7pWD1Gf6kren17QVHj7XY792Av0p d1r/aIANPswnd8dmrw/jKcL8DEZERDwrkLLzZS4IjqGEY38h4yDzwCMjOn+IVjsph+k5 2R7w== X-Forwarded-Encrypted: i=1; AJvYcCVo7dro7F+wRAHB4VKA3DfPh964XoJ93AhIpBsSEo8OvQVQpm4ASc9CFZXw/jKKMlwIsUE=@sourceware.org X-Gm-Message-State: AOJu0YxgOwKz9lnllhZtTBgLbzo83BIz56MFA1o0fabi7z+kCbHOkSrV Th9LuPsVZdlPSKm+vWQTjqm+cogLHVjVL8ONWj1CL0JnIuMnEtxgYrVWB/h5ESz71IeGYtkmpxt 2G+rDluLdmbttD1kWjJGZNNv3prV35fL8xcYfM2UL+Mum7+mS X-Received: by 2002:a17:902:d483:b0:206:aac4:b844 with SMTP id d9443c01a7336-208d97e3f78mr47263915ad.6.1726856714652; Fri, 20 Sep 2024 11:25:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHKY/r/7fjenHbkfWHiT/bJ/StAzwnMkICF9Eq2rAgnjckVWt7TDKdimTtkUkAsnD5m/CpNVQ== X-Received: by 2002:a17:902:d483:b0:206:aac4:b844 with SMTP id d9443c01a7336-208d97e3f78mr47263625ad.6.1726856714181; Fri, 20 Sep 2024 11:25:14 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20794601083sm98201465ad.71.2024.09.20.11.25.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2024 11:25:13 -0700 (PDT) Message-ID: <975a575f-1284-4902-81a9-331e4d1f90d4@redhat.com> Date: Fri, 20 Sep 2024 14:25:07 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: On pull request workflows for the GNU toolchain To: Joseph Myers , gcc@gcc.gnu.org, libc-alpha@sourceware.org, binutils@sourceware.org, gdb@sourceware.org References: Autocrypt: addr=carlos@redhat.com; keydata= xsFNBFef5BoBEACvJ15QMMZh4stKHbz0rs78XsOdxuug37dumTx6ngrDCwZ61k7nHQ+uxLuo QvLSc6YJGBEfiNFbs1hvhRFNR7xJbzRYmin7kJZZ/06fH2cgTkQhN0mRBP8KsKKT+7SvvBL7 85ZfAhArWf5m5Tl0CktZ8yoG8g9dM4SgdvdSdzZUaWBVHc6TjdAb9YEQ1/jpyfHsQp+PWLuQ ZI8nZUm+I3IBDLkbbuJVQklKzpT1b8yxVSsHCyIPFRqDDUjPL5G4WnUVy529OzfrciBvHdxG sYYDV8FX7fv6V/S3eL6qmZbObivIbLD2NbeDqw6vNpr+aehEwgwNbMVuVfH1PVHJV8Qkgxg4 PqPgQC7GbIhxxYroGbLJCQ41j25M+oqCO/XW/FUu/9x0vY5w0RsZFhlmSP5lBDcaiy3SUgp3 MSTePGuxpPlLVMePxKvabSS7EErLKlrAEmDgnUYYdPqGCefA+5N9Rn2JPfP7SoQEp2pHhEyM 6Xg9x7TJ+JNuDowQCgwussmeDt2ZUeMl3s1f6/XePfTd3l8c8Yn5Fc8reRa28dFANU6oXiZf 7/h3iQXPg81BsLMJK3aA/nyajRrNxL8dHIx7BjKX0/gxpOozlUHZHl73KhAvrBRaqLrr2tIP LkKrf3d7wdz4llg4NAGIU4ERdTTne1QAwS6x2tNa9GO9tXGPawARAQABzSpDYXJsb3MgTydE b25lbGwgKFdvcmspIDxjYXJsb3NAcmVkaGF0LmNvbT7CwZUEEwEIAD8CGwMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheAFiEEcnNUKzmWLfeymZMUFnkrTqJTQPgFAmagDwgFCRDhXm4ACgkQ FnkrTqJTQPgLlw/+JD7l4tj8l8hAMUlszrlIT6IhKSODzjrGO+6d9Y6T9vyE2kk4Xbn+kdJf uBl+wj2+U15MsQe9Z4RwowIB3YHHXgj53M2OjqOAY/sRWXZVDfmVj03hqW8D7zFxjc0SZ9cI TI0MwrDWc+Fr3naXeo7HhgjUmULfPndxb8NHVV4Ds2DTkZoUMwB8l3dboD+nKi5GbfVBf3Q5 cBw0CPkxPl0hxD9sr5IMgWIKVLtvztMIXv2xWAavqk8pQjk0zCYd46GcA8d9pZuac24e9NbM ZzTxu6cP0sKhub1JFIadyBHtJnEV/8Auc8nXJ63QY3h0QVCJYV35gQeejEdMD94in2XTkxk0 A/xCp32bmSZv5flsmdAIv5LK4jTKLvzd6BSy/v7qlpgQ7sNaxQ/JRd+8YuBIiUVIp/kgGezD qtGZSpvPCFuG3LxsdvAu7JAzBY3sfBd2lSGOeHX/JK0nQ6s97j4HlSuXIabSOdsCI5UGSOq5 thbIqfK3ewUSUB0yGvWf7EyuZugtCZOaFGpvcT3ix9/sP1fTRlJl+bNjMcO8GwedDoy85oeg yLCEV9gejCr+NijLfPYtb1s8o0hYu13uBojFyBv+bkUI5hTQaVLacq7VglA/QLOy/3mtM2v5 4OEotiNXbKypHFKnoks/MFpP4xdwxGX5jU4MgFg80aPFGr0oZVXOwU0EV5/kGgEQAKvTJke+ QSjATmz11ALKle/SSEpUwL5QOpt3xomEATcYAamww0HADfGTKdUR+aWgOK3vqu6Sicr1zbuZ jHCs2GaIgRoqh1HKVgCmaJYjizvidHluqrox6qqc9PG0bWb0f5xGQw+X2z+bEinzv4qaep1G 1OuYgvG49OpHTgZMiJq9ncHCxkD2VEJKgMywGJ4Agdl+NWVn0T7w6J+/5QmBIE8hh4NzpYfr xzWCJ9iZ3skG4zBGB4YEacc3+oeEoybc10h6tqhQNrtIiSRJH+SUJvOiNH8oMXPLAjfFVy3d 4BOgyxJhE0UhmQIQHMJxCBw81fQD10d0dcru0rAIEldEpt2UXqOr0rOALDievMF/2BKQiOA7 PbMC3/dwuNHDlClQzdjil8O7UsIgf3IMFaIbQoUEvjlgf5cm9a94gWABcfI1xadAq9vcIB5v +9fM71xDgdELnZThTd8LByrG99ExVMcG2PZYXJllVDQDZqYA1PjD9e0yHq5whJi3BrZgwDaL 5vYZEb1EMyH+BQLO3Zw/Caj8W6mooGHgNveRQ1g9FYn3NUp7UvS22Zt/KW4pCpbgkQZefxup KO6QVNwwggV44cTQ37z5onGbNPD8+2k2mmC0OEtGBkj+VH39tRk+uLOcuXlGNSVk3xOyxni0 Nk9M0GvTvPKoah9gkvL/+AofN/31ABEBAAHCwXwEGAEIACYCGwwWIQRyc1QrOZYt97KZkxQW eStOolNA+AUCZqAPEAUJEOFedgAKCRAWeStOolNA+D38D/9WnZY9fUmPhZVwpDnhIXvlXgqX cspZJEBWNS5ArFn8CLcje7z9hzX3+86lqkEeohTmlgtTg4ctZzM+XKyWSiqHCRCR+FX5SKaa 1VveBtwvjTSVmtV1m0rNHEvUZ5x47A8NadWqYi6uOQ22FhEqUOiwJ7EHzk4w9W3gT1913XT1 vmkCn6FtQcrQvJT7pP+oA0YIVs8ADayJcqWHM+Ez7L2fpfAzBDhIS7dq2MYU8LQOQAsx1y7H 6njp5dN/OI/aN/RL6XeX1Kxl4Xe+hc+tq457fLAUnmaevUldvKThuj+5/Cd4DW25MxaqinfY m/U6pBQ4ZwQPGWA0f+GKiJcLosSRXxIuEdZAl82ht+KgT3zhV/BvQRmrD6wX3ywPkJap8h4K ibwz3r6NbHKdCX22ok58oE8NAWtmTRTKXDhh8oWOKdIYjX6jJzdb/F8rPNoEY3UiYbaNTxt5 TE9VD+yWilYO796HMXjXenCOlghy3HFmZbsQ4N+FlG6LQD7cnwm56kcrJk1IlnQXOSOd2BA2 qNbM1Ohry3B+1F4Oaee+ZKH2C5y7Kx0y3m1b5X7Wpx76H5BeUAp6dQi6nNYeqM9PglZIMvSe O4uRThl5mMDx8MXQz6M9qQ5anYwre+/TudTfCzcTpgXod1wEqi2ErJ5jNgh18DRlSQ3tbDvG O0FatDMfJw== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Carlos O'Donell via Gdb Reply-To: Carlos O'Donell Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 9/19/24 11:51 AM, Joseph Myers wrote: > 1. Introduction Thanks for writing this up! > This message expands on my remarks at the Cauldron (especially the > patch review and maintenance BoF, and the Sourceware infrastructure > BoF) regarding desired features for a system providing pull request > functionality (patch submission via creating branches that are then > proposed using some kind of web interface or API, with a central > database then tracking the status of each pull request and review > comments thereon automatically), for use by the GNU toolchain (or one > or more components thereof - there is no need for each component to > make the same decision about moving to such software and workflow, and > indeed we have no mechanism to make such decisions for the toolchain > as a whole). > > This does not advocate a particular choice of software for such > functionality (though much of the discussion seemed to suggest Forgejo > as the most likely starting point), or a particular choice of where to > host it. Hosting would of course need to meet appropriate security > requirements, and to achieve a passing grade on the GNU Ethical > Repository Criteria, and the software would need to be entirely free > software. Where relevant features are not already supported, it's > important that the software is receptive to the addition of such > features (including cases where part of the functionality is provided > by software specific to the GNU toolchain or parts thereof - such as > for the custom checks currently implemented with git hooks - and the > underlying software provides appropriate interfaces to allow > integration of such external pieces). The list of features here may > be a good basis for reviewing what particular forge software supports > and whether other features can be added, directly or through use of > appropriate APIs. > > Forge software may provide other pieces such as bug tracking or wikis > that we currently handle separately from git hosting. In such cases, > we should be able to disable those pieces and keep using the existing > bug tracking and wiki software (while having the option to decide > independently to migrate those if desired). > > I consider the overall benefits of such a move to be having more > structured data about all changes proposed for inclusion and their > status (needing review, needing changes from the author, under > discussion, needing merge from mainline, etc.), to help all people > involved in the patch submission and review process to track such > information and to find patches needing review as applicable, along > with providing a more familiar workflow for many people that avoids > many of the problems with email (which affect experienced contributors > working around corporate email systems, not just new contributors). > It would not of course by itself turn people with no interest in or > understanding of systems software development into contributors (for > example, people without knowledge of directories and hierarchical file > storage, or people who only understand software development as web > development). Nor would it prevent the accumulation of large backlogs > of unreviewed patches, as is evident from many large and active > projects using PR workflows with large numbers of open PRs. > > As Richard noted in his BoF, email sucks. As I noted in reply, so do > the web and web browsers when trying to deal with large amounts of > patch review state (when one wishes to apply one's own view, not the > forge's, of what is resolved and what needs attention). As I also > noted, in the Sourceware infrastructure BoF, tools such as patchwork > and b4 are the right answer to the wrong question: trying to get > structured data about patch submissions when working from the axiom > that emails on a mailing list should be the primary source of truth > for everything needing review, rather than starting from more > structured data and generating emails as one form of output. > > Moving to a pull request system is not expected to change policies > regarding who can approve a change for inclusion, or the technical > limits on who can cause a change to enter mainline (e.g. all people > with commit access would be expected to be able to use a button in a > web interface to cause to PR to be merged, though policy might limit > when they should do so). We can of course choose to change policies, > either as part of adopting a PR system or later. Agreed. > > > 2. Key features > > (a) Some forges have a design that emphasises the tree you get after a > proposed contribution, but not the sequence of commits to get there. This has changed a lot in recent years in gitlab and github where per-commit reviews were emerging as a needed property of the web UI, so the commits (rather than the final state of the tree) were being exposed for review purposes. I see this as a general maturing of the tooling towards what we already knew in systems design, that the commits and the clean logical changes were a necessary prerequisite to managing the complexity of the change. > For the toolchain, we care about the clean, logical sequence of > commits on the mainline branch. (We also use linear history on > mainline, but that's a secondary matter - though certainly we'd want > any forge used to support such linear history so that property doesn't > need to change as part of adopting pull request workflow.) Having a > clean sequence of commits has some implications for forge support: > > * Support for reviewing the proposed commit message, not just the > diffs, is important (and it should be clear what commit message > would result from merging any pull request). > > * Patch series and dependencies between patches are important. In > such cases, fixes for issues from review should go into the > appropriate logical commit in the PR (with rebasing as necessary), > and it should be possible at all times to see what the sequence of > commits on mainline would look like. (E.g. people use some > workarounds on GitHub to manage PR dependencies, but those result in > second and subsequent PRs in a series showing the full set of diffs > from a PR and those it depends on, rather than just the logical > diffs for one PR.) This area has seen a lot of change recently in the large forges, and warrants a review of current offerings. > I consider patch series and dependencies to be separate but related > things: a patch series may not have strictly linear dependencies > (and it's often useful to merge the more straightforward patches > from a series while still discussing and revising others), while a > patch may depend on other patches that it's not logically part of > the same series as. They are, however, closely related, and a > sufficient solution for dependencies might also be adequate for many > cases of series. Agreed. > Note that series can sometimes have hundreds of patches; any > solution for patch series and dependencies needs to scale that far. > > There is of course the common case of a single-patch submission, > where the patch is ready for inclusion after some number of fixes. > In those cases, it's probably convenient if it's not necessary to > rebase - provided it's clear that a particular PR would be > squash-merged, and also what the commit message would be for the > final fixed commit. > > * Given the need for rebasing when working with patch series, it's > important to have good support for rebasing. In particular, all > revisions of the changes for a PR that was rebased need to remain > permanently available (e.g. through appropriate documented refs to > fetch to get all revisions of all PRs). > > (b) Various people have built efficient workflows for going through > all patch submissions and comments (or all in a particular area), even > when only reviewing a small proportion, and have concerns about > efficiency of a web interface when working with many patches and > comments. It's important to have good API support to allow people to > build tools supporting their own workflow like this without needing to > use the browser interface (and following their own logic, not the > forge's, for what changes are of interest). Good API support might, > for example, include a straightforward way to get all changes to PR > and comment data and metadata since some particular point, as well as > for actions such as reviewing / commenting / approving a PR. Such API > support might be similar to what's needed to ensure people can readily > get and maintain a local replica of all the key data and its history > for all PRs. Agreed. > Replication like that is also important for reliably ensuring key data > remains available even if the forge software subsequently ceases to be > maintained. Consider, for example, the apparent disappearance of the > data from www-gnats.gnu.org (we occasionally come across references to > old bug reports from that system in glibc development, but don't have > any way to resolve those references). > > Another use of such an API would be to allow maintaining local copies > of all PR comments etc. in a plain text form that can be searched with > grep. > > (c) Given that a transition would be from using mailing lists, it's > important to have good plain text outward email notifications for all > new merge requests, comments thereon and other significant actions > (changing metadata, approvals / merges, etc.) - through whatever > combination of built-in support in a forge and local implementation > using the API. Such notifications would go to the existing mailing > lists (note that the choice of mailing lists for a patch can depend on > which parts of the tree it changes - for example, the choice between > binutils and gdb-patches lists, or some GCC patches going to the > fortran or libstdc++ lists) - as well as to individuals concerned with > / subscribed to a given PR. Some very routine changes, such as > reports of clean CI results, might be omitted by default from > notifications sent to the mailing lists. > > "good" includes quoting appropriate diff hunks being comments on. > It's OK to have an HTML multipart as well, but the quality of the > plain text part matters. Diffs themselves should be included in > new-PR emails (and those for changes to a PR) unless very large. > > I do not however suggest trying to take incoming email (unstructured) > and turn it into more structured comments on particular parts of a PR > in the database. Agreed Re: incoming email. > Similarly, commit emails should continue to go to the existing mailing > lists for those. > > (d) Rather than the forge owning the mainline branch in the sense of > every commit having to go through an approved PR, at least initially > it should be possible for people to push directly to mainline as well, > so the transition doesn't have to be instantaneous (and in particular, > if a change was posted before the transition and approved after it, it > shouldn't be necessary to turn it into a PR). Longer term, I think it > would be a good idea to move to everything going through the PR system > (with people able to self-approve and merge their own PRs immediately > where they can commit without review at present), so there is better > structured uniform tracking of all changes and associated CI > information etc. - however, direct commits to branches other than > mainline (and maybe release branches) should continue to be OK long > term (although it should also be possible to make a PR to such a > branch if desired). > > Beyond putting everything through PRs, eventually I'd hope to have > merges to mainline normally all go through a CI system that makes sure > there are no regressions for at least one configuration before merging > changes. Agreed. > (e) All existing pre-commit checks from hooks should be kept in some > form, to maintain existing invariants on both tree and commit contents > (some hook checks make sure that commits don't have commit messages > that would cause other automated processes to fall over later, for > example). These could all move to pre-commit CI checks that block merging. > (f) Existing cron jobs that read from or commit to repositories should > use normal remote git access, not filesystem access to the repository, > including using APIs to create and self-merge PRs when pushing to the > repository is involved. Agreed. Thanks for writing this up! -- Cheers, Carlos.