From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id E57BB3858C52 for ; Fri, 23 Sep 2022 14:04:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E57BB3858C52 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52f.google.com with SMTP id e18so381540edj.3 for ; Fri, 23 Sep 2022 07:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:subject:from:to:content-language :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date; bh=mAcp26nevtDo92hVJ3z/atWo3E1detnN6oqomREcv+U=; b=IMk4W2SIyM/C0CZYVI2pWLzA3LwrtQ6Yr2SMCEZdAAHikZBYj17a7JO1z/kZPeK43N c9ioRfKyXl8gks7IZ4vm0ifRROa6rk4jDLePJ9UX9Z/HHi7/3w6EQbQYuVxK55/+YoLC Ssyyc3jx/RyLMYCA7rusesVk4iOsWRRxwd7Du9yKa8QXKYbubbFyGo+4A/Q24ci3zHEA C8J0VJ5/RDq7qdJYkvck0Z3Zb3F04lgOe+2HF9f8RPFNr1DzhlAASq9NW/uqaltFulIp bGNCy1o/dpgBNxL7FsKQPfMMzmTxgo2Mbjx2C5R/9MDMpIQ1q2yn8F1YdGy2dQ48vkp6 /S0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:subject:from:to:content-language :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date; bh=mAcp26nevtDo92hVJ3z/atWo3E1detnN6oqomREcv+U=; b=yC0kKvLqxY8DOvQrbtWEWzmLXiklmUR9w1McnXBU6xVsEm69AUFqr0Yx/UNHuxOeZp PmEaTArEwwctlP34Fdkyiwgil8LzRiOnrYodVTghzRbRKQODFiMH4+ptFQETj3qAbk1d a1gwoogN7rIxZFNEWo2ya/wrhJE1e7FQWwnodkm9A51Wh43DcNfrX5dbfWagGSMIFdtR O6yl9vVAsVjyUFHiiraMS7ATgEB4vloi5cumLEs0NJdSu917jQjYiXdb2jsUCLxNakpm NFsmdTc6sxh6CGkqIHmd1fDDGMhDwvdQ3O6lckG4nSXzjgCFKvhFjvI3buDOHTP9YtLm CTpw== X-Gm-Message-State: ACrzQf2qzO666tQ2d34JWiJywrxbxsRF/uS3Nb1CMCYRCzp/ERbw8+ho ifyMzGL6SlgWmBKrVzfpo8lBf29ng6s= X-Google-Smtp-Source: AMsMyM4D13fawg6+Gzv/u7Qw/XBgHB91awMQ7Z5n7QNSFwj+Uc7VtkFd9cFFqe5NPdhVYoO15Fs3+g== X-Received: by 2002:a05:6402:1ad1:b0:44e:8dfb:2d04 with SMTP id ba17-20020a0564021ad100b0044e8dfb2d04mr8385403edb.400.1663941854459; Fri, 23 Sep 2022 07:04:14 -0700 (PDT) Received: from ?IPV6:2001:b07:6468:f312:9af8:e5f5:7516:fa89? ([2001:b07:6468:f312:9af8:e5f5:7516:fa89]) by smtp.googlemail.com with ESMTPSA id g13-20020a170906538d00b0073100dfa7b0sm4088622ejo.8.2022.09.23.07.04.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Sep 2022 07:04:13 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <58991505-d402-bc5f-5ee8-fff48dcde6cd@gnu.org> Date: Fri, 23 Sep 2022 16:04:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Content-Language: en-US To: overseers@sourceware.org From: Paolo Bonzini Subject: Role of sourceware for hosted projects Cc: Bradley Kuhn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: Hi all, I have recently come across the discussions at Cauldron about Sourceware, by means of an article on LWN.net. Even though I have not been a contributor to Sourceware projects for several years, they are still dear to my heart and I am familiar with several of them. Therefore, I would like to share my own observations about what sourceware.org can or should provide to the project it hosts. First of all, a few obligatory pieces of disclosure. First, I am employed by Red Hat but not for anything related to the GNU Compiler Collection or any other Sourceware project. Second, I was not at Cauldron and have only watched the online recording of the first hour of the BoFs; I trust the LWN.net editors and their article on the topic to provide a faithful account. Third, even though I have discussed this with some of the people involved in the BoFs, that hasn't substantially changed my understanding of the situation as it is reflected below. The obvious observation from the outside is that the two "opposing sides" (for lack of a better word) have different priorities on what Sourceware needs to provide for them. There are several reasons for this: different projects that people work on, different emotional attachment, different jobs, whatnot. However, both of them make the same mistake: they focus on the "next steps" without a full assessment of the *current* state of Sourceware. The first part of the assessment in my opinion should be that most projects on sourceware.org are dead. Some of them (e.g. GSL) have already migrated out of Sourceware in fact, but the others should be archived ASAP. Archival means moving them to a different domain *and machine*, with redirects put in place on the sourceware.org website. The machine should not provide any maintainer of archived projects with shell access. Archived projects can have a static website and have their sources available via git/gitweb, but no mailing lists, no bug tracking, no wiki, and no code running on the server such as commit hooks or CGI scripts. Archiving these projects or turning their pages into hard redirects will leave if I counted right, roughly ten projects that are alive: gcc, gdb, binutils and glibc ("the GNU toolchain"); elfutils, systemtap, cygwin/newlib and libabigail ("smaller projects"); and others that are alive but barely so (debugedit, dwz, etc.). Also, most projects outside the GNU toolchain have only one main developer. That's quite a varied lot, enough so that: 1) it does seem weird for Conservancy to be the fiscal sponsor for *Sourceware*, which is essentially "a machine" rather than a coherent/cohesive set of projects. *Some* of the smaller projects might very well be interested in joining Conservancy, but different maintainers may have different requirements or priorities. 2) Migration to IT infrastructure hosted by Linux Foundation, as in the "GTI" proposal, might not take into account the needs of smaller projects very well. But there is no reason for these projects to live on the same server or have the same development model; and there's no reason for all of the services to be provided by a single server. Different services can be easily outsourced to different people, companies or external providers. Based on the above, I think focus should be on simplifying the sourceware.org infrastructure, removing unnecessary services based on ease of migration, attack surface, operating cost (both human and monetary). This way Sourceware handles on what is harder to obtain from external providers, and projects can use the best external infrastructure for everything else they need. A prime target for this simplification, based mostly on my experience with QEMU, is source control and CI. My understanding is that GTI comes from maintainers that are not confident that Sourceware can provide enough security---not because they do not trust the overseers, but rather because things go well until they don't. For this reason, source control is the main concern of the people behind the GTI proposal. If the bigger projects are worried about supply chain attacks, to begin with they can very easily migrate their source code control repositories elsewhere. It could be operated by LF staff, or could be a "forge" like Gitlab/GitHub; several projects use the latter purely for hosting while keeping development on mailing lists. They don't even have to do the same thing between the four of them, though it would make sense for at least binutils, gcc and gdb to do so. I am rusty on how these three projects do release management, but perhaps they could even use a monorepo with per-project release branches, and tarballs that only include the relevant directories. But while GTI focuses (as expected) on the four GNU projects that form the toolchain, Sourceware infrastructure might not be the most suitable even for smaller projects. In fact, in my humble opinion maintainers of smaller and moribund projects should *also* figure out if they still need/want the infrastructure provided by sourceware.org. Of the smaller projects, most might be better served by migrating to Gitlab or GitHub; for example, CI there is easier to use than custom infrastructure based on patchwork and buildbot. Sourcehut is another possibility; it scores pretty high on the GNU Ethical Repository Criteria, especially with respect to free Javascript, and some maintainers might value that as well. Therefore, even though in the short term Sourceware can also host source code control repos for the smaller projects that do not want to migrate, I believe that this should be phased out for all non-archived projects. Distributed version control makes migration easy enough, and backwards-compatible HTTP-level redirects are easy to set up for git, gitweb and also the websites. The remaining common needs of large and small projects alike seem to be mailing lists, where migrating to a new domain and preserving archives can both be painful endeavors; bug tracking, for similar preservation reasons; and possibly a wiki. Reducing Sourceware to these three services would reduce the operating cost (bandwidth for downloads and source control often dwarves everything else) and the attack surface. While other services such as patchwork can be included, they fall more into a nice-to-have category and might not be completely indispensable when they break. This also makes them easier to manage, and not a primary component of the sourceware "bus factor". That's all. I admit I am not necessarily up to date on how Sourceware operates, so I apologize in advance for any incorrect assumptions I made. Apart from that, I hope that this writeup can provide useful ideas, or even a path forward for both Sourceware and the GNU toolchain. Thanks, Paolo