From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110448 invoked by alias); 6 Feb 2020 15:10:26 -0000 Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org Received: (qmail 110435 invoked by uid 89); 6 Feb 2020 15:10:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=8.5, backed X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2020 15:10:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581001821; 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=JkYY2Sf4RcoOJdRPcYeZVz4bC7B468d+fuyvdmJGG1E=; b=LLmRapaJko6UDAiAiA0JHAJJIWsMzxz1nNQpTwb1rYfOYgD3nAmdNjaVJIFLLpl+nuLl5f YdZEiJpzl9Jh5kahUKtuN5m9VROyoMx76QMDI32LpFIL6cPksxggYiYK5tyfTTpzJZT7Ko C0W80jev0G7g4FmI5HChcxB7FWtMIgE= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-208-5fWPkZM7NZGFb7jflIKSbQ-1; Thu, 06 Feb 2020 10:10:20 -0500 Received: by mail-qk1-f197.google.com with SMTP id f22so3769623qka.10 for ; Thu, 06 Feb 2020 07:10:20 -0800 (PST) Return-Path: Received: from [192.168.1.4] (135-23-175-75.cpe.pppoe.ca. [135.23.175.75]) by smtp.gmail.com with ESMTPSA id d18sm1550436qke.75.2020.02.06.07.10.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Feb 2020 07:10:18 -0800 (PST) Subject: Re: Choice of distribution for new sourceware.org server? To: "Frank Ch. Eigler" Cc: overseers@sourceware.org, Florian Weimer References: <74e963de-f7c8-33d0-d133-ada427c000a4@redhat.com> <20200206013050.GA16275@cgf.cx> <20200206013405.GC97355@elastic.org> <20200206020237.GD97355@elastic.org> <20200206144908.GG97355@elastic.org> From: Carlos O'Donell Message-ID: <177b7cdc-bf88-a004-6f3d-9fb4c8a65da7@redhat.com> Date: Thu, 06 Feb 2020 15:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200206144908.GG97355@elastic.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00070.txt On 2/6/20 9:49 AM, Frank Ch. Eigler wrote: > Hi - > >>>> How much non-distro software is there on sourceware? >>> Well, quite a bit. >> >> If non-distro softare impacts our maintenance costs, should we be evaluating >> the list of non-distro software for value vs. cost? > > We evaluate regularly. It's not just software that substitutes for > distro bits (there's only a bit of that). Remember things like > multiple wikis, bugzilla. Awesome. Do you need any help with regular evaluations? Is there a meeting for that? Or is this tactically driven when something can't be upgraded? I'm surprised the wiki is non-distro software. I recently setup a dokuwiki backed by git, and it was all distro-software with just configuration data. Moinmoin is basically dead upstream. Dokuwiki is actively maintained and there are migration paths from moinmoin to dokuwiki. Also if we did a git-backed wiki we could use the same git access mechanisms for the wiki and not maintain distinct lists of users! And I would switch to gitolite following the kernel's lead here for serving git, and we could do that with relatively little effort (pickup all the pub keys people have, populate gitolite keysdir and copy the raw git repos). This would also allow us to restrict shell access to only those that ask for it and thus limit our security exposure (best practice). Then we'd only have one process for registration, hand over your pub key, and you get immediate access to git, including the wikis now stored in git. >>>> When you say "activity" do you mean that users would be impacted >>>> once every 8 months for a small window of downtime? >>> >>> Probably, if nothing goes wrong. And if there's an incompatible >>> rebase of python or php or whatever, then we (?) have to fix the >>> thing. There is a downside to upgrade churn, in terms of our >>> manpower. >> >> Best practice is to have a production and development server to >> avoid these kinds of problems and shake out such changes. >> Do we have 2 servers now? > > rawhide level upgrade churn has to bring tangible value that is in > excess of the costs (to all the parties, not just users). I agree completely. I don't suggest we run Rawhide at all. >> In which case RHEL8 with ELS as an option is even more valuable? > >> In summary: >> - Why not stick with RHEL8 to get ELS and avoid CentOS 8 early phase out. > > Already said I'll look into moving from centos8 to rhel8. centos > lifespan does not look materially different from rhel. CentOS 8 is EOL when RHEL 8 ELS starts. RHEL 8's lifespan is 10 years, with RHEL 8 ELS adding another 4-5 years of support. That's almost a 50% increase in lifespan to schedule and upgrade. That looks materially different to me and impactful for managing the upgrade. CentOS 8 forces you to keep upgrading through the changing y-stream. Some y-stream upgrades for AppStream may be rebases of pakcages that break your deployment. With ELS you can camp out on RHEL 8.4 *without* upgrading to RHEL 8.5/8.6/8.7, and then upgrade to RHEL 8.8. It gives you the flexibility to camp out on an ELS release and schedule around the upgrade. Please review the following details: https://access.redhat.com/support/policy/updates/errata We would have to ask Red Hat for licenses. -- Cheers, Carlos.