From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id C883D3858D3C; Fri, 7 Oct 2022 13:39:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C883D3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A06833021EAC; Fri, 7 Oct 2022 15:39:48 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A5B93400B8BD; Fri, 7 Oct 2022 15:39:47 +0200 (CEST) Message-ID: Subject: Re: The GNU Toolchain Infrastructure Project From: Mark Wielaard To: Siddhesh Poyarekar , Overseers mailing list , gcc@gcc.gnu.org, libc-alpha@sourceware.org, binutils@sourceware.org, gdb@sourceware.org Date: Fri, 07 Oct 2022 15:39:47 +0200 In-Reply-To: References: <6f6d141b-b776-8707-2c91-dc38d20aa9e1@gotplt.org> <20221004171007.oc2ot6eu6l24aipn@cgf.cx> <05b0f7fa-7077-5a8b-0c2f-dfb3068dd10f@gotplt.org> <20221006201256.run7acqpnjofsqfw@cgf.cx> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3033.5 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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, On Thu, 2022-10-06 at 17:37 -0400, Siddhesh Poyarekar wrote: > Also as I responded to Mark, the technical details of the transition are= =20 > the responsibility of the GTI TAC (which you were invited to be member= =20 > of and you declined) and not the LF IT, although they'd be the ones=20 > implementing and maintaining it. >=20 > We're at that stage at the moment where we look for consensus from the= =20 > project communities so that we understand if we can move all of=20 > sourceware to LF IT or if we need both to coexist somehow. >=20 > Once we have a direction, we talk about what that transition would look= =20 > like and ask questions accordingly. Are there services that you=20 > absolutely cannot move to LF IT and why? Why would you support (or=20 > oppose) porting the wiki to something like readthedocs backed by a git re= po? >=20 > I respect your outright rejection of the proposal because at least it is= =20 > clear that you don't have any stake in its fine tuning. Lets try to make this a little less adversarial. This doesn't have to be a clash of communities where there can be only one. Yes, the way this was introduced caused things to become very contentious. But at Cauldron we also agreed to bring this proposal to the overseers list and discuss it together. Of course we can coexist. Lets do a reset. Now that the plans are more public there will hopefully be less opportunity for speculation and misunderstandings. But there are still some unclear details and people have had various (unanswered) questions. It would be good to get answers to the questions people asked on overseers. And it would be great if the GTI TAC members discussed how they see the technical details of various services on the overseers list. We can then file specific sourceware infrastructure bugs to track the various technical needs from a community perspective. And hopefully we can then, as one community, take up shared responsibility of how to move things forward together. Cheers, Mark