From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 75BE03858CD1 for ; Fri, 14 Jul 2023 11:38:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 75BE03858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689334687; 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; bh=c36BDOGpDW+dy4P0V3WtUiT5fHWJv+BjwvSi6mJi+NA=; b=jKTbiLWxrn5Rfz0yJLaxLzCv03Re4NiUIAo71KQ37nA/UmKYbsSJhh+4SswJKccxVxdbvk M74mqfVShNiuM6AYNKPyHHlp1zrBq7xDofsCRP7JwC/rMz4fNuC8XnReY8zy2rPOgo5V6d XEOsbs2PRjwhbmXSPxWsOTMJ9Cp9ZwQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-652-hB-PlJY3PqKLmSxLZRM9Rg-1; Fri, 14 Jul 2023 07:38:04 -0400 X-MC-Unique: hB-PlJY3PqKLmSxLZRM9Rg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2ED648D1691; Fri, 14 Jul 2023 11:38:04 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E78E40C6CCC; Fri, 14 Jul 2023 11:38:02 +0000 (UTC) From: Florian Weimer To: Carlos O'Donell via Libc-alpha Cc: Carlos O'Donell , Konstantin Ryabitsev , Joseph Myers , "Ryan S. Arnold" , Paul Eggert , Jakub Jelinek , Maxim Kuvyrkov , Andreas Schwab Subject: Re: Core Toolchain Infrastructure - Services for glibc References: <45e98807-908f-0968-b6fe-5dbb0af265b1@redhat.com> Date: Fri, 14 Jul 2023 13:38:00 +0200 In-Reply-To: <45e98807-908f-0968-b6fe-5dbb0af265b1@redhat.com> (Carlos O'Donell via Libc-alpha's message of "Thu, 13 Jul 2023 17:58:14 -0400") Message-ID: <87ttu6oh9j.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: * Carlos O'Donell via Libc-alpha: > * Mailing lists > * Support public-inbox for mailing list archives. > * Use of public-inbox means archives can be cloned and copied. > * Use of LF IT Subspace mailing list services (mlmmj, postfix). I assume LF IT is able to run mailing lists without =E2=80=9Cvia=E2=80=9D F= rom: rewriting? > * bug database > * Consider starting fresh in new Bugzilla 5.0.4+ instance and freeze old= product. > * glibc component in sourceware instance marked "Not open for new bugs." > * No easy way to clone this but we can discuss options. > * Isolate bugzilla from other services. Does LF IT offer some Bugzilla anti-spam services? To what extent do we need to constrain new sign-ups? We have one custom extension I know of: suppressing notifications when setting security+ because it was deemed too noisy for old bugs. This should not be necessary anymore; most of the bugs missing security+ analysis are current. > * git > * Migrate to gitolite > * Community manages access via gitolite keys. > * Minimize all access to sources and isolate from other processes. > * Minimal server side web hooks where required. > * Isolate git service from other services. > * Stop supporting svn/cvs and provide tarball dumps. 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? > * wiki > * Migrate to git-based documentation with existing content copied over. > * Suggest rst/Sphinx or similar to existing discussions for GCC docs. > * Sphinx with themes can provide a lot of flexibility for display. > * Isolate wiki service from other services. Will this be a separate Git repository, with different commit rules? I do not particularly like the current MoinMoin wiki, but at least it has a preview button. We'd lose that with a pure Git-based workflow. > * Website > * Provide a simple static site. > * Isolate web hosting from other services. How do we keep the online manual up-to-date? > * Meeting > * Already migrated away from proprietary solutions. > * Continue to use LF IT BBB instance for glibc meetings including weekly= patch review. > * Isolate BBB from other services. Ironically, with that move we lost support for open standards like SIP dial-in. I assume there is no plan to bring that back, as the SIP situation with BBB isn't great. Thanks, Florian