From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id 94B643858C53 for ; Sat, 4 May 2024 19:56:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 94B643858C53 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=kitware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kitware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 94B643858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::731 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714852579; cv=none; b=Wb5TIoVQ30Q0SuLEaSqi8uNdsrR9YWmq+eiaTUo6pzYx6dui+bZAFJhxt6HGKrwr6fmMh00m+vPw8Lclgl4j00Lm3O6TvPd2zws72ztWfC87a7GjNQ2RxV304wYSUHnqhpK+oi1Pd3YxKFkC5pzEDl5SvHzxqiNpY3AxlYgxVhU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714852579; c=relaxed/simple; bh=//DT8VZRiksm+yUmbzjeeE4xPTYJNZKzbA/3wCRf0vM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=dqbOtYxtwADiqFnvh0bnmZVk6IlHRMX5gSEKzLfC4DAhG/fBJ6vfFDOAa9kzx3qCA5PyJ7XHvawVGkS7jFbe36l48BFeGAZ/Hjdgh6J4zlPTAAWWcVuyYsgdgjORj0XaOnlAob66W8d2flVOMcNirmISjNG+phbaqipzdOrALr8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-79291262e7cso38278085a.2 for ; Sat, 04 May 2024 12:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kitware.com; s=google; t=1714852575; x=1715457375; darn=sourceware.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=XaHEAgrzxv2BnqScmWA3/aMcRBIB2MSx+Q1/cwa0NKs=; b=vNYRZL0n7j+o0SE333OPvA7FLuozJTTpFCS3XZfVKeR28c3xc4QFTpUoJe3+noAfRE 650AZhRiWuVITVwt2ZHXxkBoe9pwsKn5pFgtA836H0W18pXXZQOUr+/lbV1e6Ml+CwKr 6b5rkAgUb76e62d9mrkpU5G8n79Deu0nRuOU4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714852575; x=1715457375; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XaHEAgrzxv2BnqScmWA3/aMcRBIB2MSx+Q1/cwa0NKs=; b=knhT2wPTM3wW5CMRngpoepmx79THYu8njCxi8B96LZSHE+qnr2Z068p20GZFSfp8za d20sCLl9zlL9WCBxpJ32KzSlB/7XntRPw8faS0WOqr+ymxPAcne+RHL/SkT+BQ81ZzEd PwUxselJ9Z7A6/ToC9unAgZvW9reqK5oS0K9VccYBCoto4VK5044/1AD9Gip/RkC1TKI zYLiRAMPdPp1Ser1BkliiyzTXWqe14CweWAauX/0qcrFdZEyYIPdSOb/3yrir8q4U3/f rfRi+cOZ3Ykh/msWnel9giSu8tf5oXD/HYLqMO6MRV79cwyklfjhgD/cGS/1Jpnj44Od fIwQ== X-Forwarded-Encrypted: i=1; AJvYcCUtwT7pJQDipZscAg5Ua3Midb5e774w/yY1F9f6bEJPiMcw2crlpL3RfW46qOuQoa3yz3hldLAb7bR8vJnZ+B8cgx9DqrEvfA== X-Gm-Message-State: AOJu0YwNsXqclymUfSRMsyS5bJksl+22K2q5RvSOZjrybqSGxasFiHK1 MzLu2jSCtG1HX+w2SN3Jf3JY+fyn1wntpHBXfy4WNhh7dbQ8DODVH9/bilDl8Q== X-Google-Smtp-Source: AGHT+IFrbTG2MOQbVl9qnJWhT2GjVMPdzR7LofJOqRLngZPz9Efy34M79OyIBPwsvZD4qHytXh+VUg== X-Received: by 2002:a05:622a:164b:b0:43a:d899:9089 with SMTP id y11-20020a05622a164b00b0043ad8999089mr8000480qtj.41.1714852574871; Sat, 04 May 2024 12:56:14 -0700 (PDT) Received: from localhost (syn-142-105-146-128.res.spectrum.com. [142.105.146.128]) by smtp.gmail.com with ESMTPSA id bn4-20020a05622a1dc400b004378ec294f9sm3156316qtb.72.2024.05.04.12.56.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 May 2024 12:56:14 -0700 (PDT) Date: Sat, 4 May 2024 15:56:12 -0400 From: Ben Boeckel To: Mark Wielaard Cc: Jason Merrill , Jeff Law , "Frank Ch. Eigler" , Overseers mailing list , Joseph Myers , gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org, Tom Tromey , Sergio Durigan Junior Subject: Re: Updated Sourceware infrastructure plans Message-ID: 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> <20240501212618.GB6469@gnu.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240501212618.GB6469@gnu.wildebeest.org> User-Agent: Mutt/2.2.12 (2023-09-09) X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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, May 01, 2024 at 23:26:18 +0200, Mark Wielaard wrote: > On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote: > > Do you (or others) have any thoughts about GitLab FOSS? > > The gitlab "community edition" still feels not very much "community". > We could run our own instance, but it will still be "open core" with > features missing to try to draw you towards the proprietary hosted > saas version. Also it seems to have way too much overhead. The focus > is clearly corporate developers where managers want assurances the > mandatory "pipelines" are executed and "workflows" followed exactly. I'll offer my experience here. We (at Kitware) have been using GitLab FOSS for around 8 years. We can't use the other editions because of the per-account pricing and having open registration (since pretty much everything there is FOSS code). GitLab is receptive to patches sent their way and have considered moving things to the FOSS edition to help large FOSS organizations (freedesktop.org, GNOME, KDE, probably others too). There's also been discussion of implementing features such as commit message review in order to court Linux developers given forge-like discussion happening there. FWIW, Fedora is also looking at forges as well: https://discussion.fedoraproject.org/t/2024-git-forge-evaluation/111795 That said, there are definitely gaps to fill. We have our tooling here: https://gitlab.kitware.com/utils/rust-ghostflow (core actions) https://gitlab.kitware.com/utils/ghostflow-director (service deployment) We use it to implement things including: - Basic content checks (scripts are executable, no binaries, file size limits, formatting, etc.) either on a commit-by-commit basis or by looking at the MR (patch series, PR, whatever the forge calls it) as a whole. Docs for currently-implemented checks are here: https://gitlab.kitware.com/utils/rust-ghostflow/-/blob/master/ghostflow-cli/doc/checks.md - Reformatting upon request; if the formatter(s) in use supports writing the content as intended, there is code to rewrite each individual patch to conform. This avoids wasting time on either side for things that can be done automatically (of course, you're also at the mercy of what the formatter wants…I find it worth it on balance). - More advanced merging including gathering trailers for the merge commit message from comments and other metadata including `Reviewed-by` and `Tested-by` (also from CI). Also supported is merging into multiple branches at once (e.g., backports to older branches with a single MR). - Merge train support (we call it the "stage"); this feature is otherwise locked behind for-pay editions of GitLab. Right now, GitLab and Github are supported, but other forges can be supported as well. In addition to the service (which is triggered by webhook delivery), there's a command line tool for local usage (though it only implements checking and reformatting at the moment mainly due to a lack of available time to work on it). There are other things that are probably of interest to supply chain or other things such as: - every push is stored in a ghostflow-director-side unique ref (`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid forge-side garbage collection (especially problematic on Github; I've not noticed GitLab collecting so eagerly) - all webhooks are delivered via filesystem and can be archived (`webhook-listen` is the program that listens and delivers them: https://gitlab.kitware.com/utils/webhook-listen); events which trigger failures are stored with some context about what happened; those that are ignored are stored with a reason for the ignore (see this crate for the "event loop" of `ghostflow-director` itself: https://gitlab.kitware.com/utils/rust-json-job-dispatch) - the forge is the source of truth; if a ref is force-pushed, `ghostflow` will accept the state on the forge as gospel instead; the only non-logging/historical tracking state off-forge includes: - the config file - formatter installation (formatting is designed to only use trusted binaries; nothing from the repo itself other than which to use) On the first two points, we had some data loss on our instance once and using the webhook history and stored refs, I was able to restore code pushed to projects and "replay" comments that happened since the last backup (I copied the content and @mentioned the original author). > At the moment though the only thing people seem to agree on is that > any system will be based on git. So the plan for now is to first setup > a larger git(olite) system so that every contributor (also those who > don't currently have commit access) can easily "post" their git > repo. This can then hopefully integrate with the systems we already > have setup (triggering builder CI, flag/match with patchwork/emails, > etc.) or any future "pull request" like system. As a fellow FOSS maintainer I definitely appreciate the benefit of being email-based (`mutt` is far better at wrangling notifications from umpteen places than…well basically any website is at even their own), but as a *contributor* it is utterly opaque. It's not always clear if my patch has been seen, if it is waiting on maintainer time, or for me to do something. After one review, what is the courtesy time before pushing a new patchset to avoid a review "crossing in the night" as I push more patches? Did I get everyone that commented on the patch the first time in the Cc list properly? Is a discussion considered resolved (FWIW, Github is annoying with its conversation resolution behavior IMO; GitLab's explicit closing is much better). Has it been merged? To the right place? And that's for patches I author; figuring out the status of patches I'm interested in but not the author of is even harder. A forge surfaces a lot of this information pretty well and, to me, GitLab at least offers usable enough email messages (e.g., discussions on threads will thread in email too) that the public tracking of such things is far more useful on the whole. --Ben