From owner-svn-src-stable-11@freebsd.org Mon Apr 2 16:28:09 2018 Return-Path: Delivered-To: svn-src-stable-11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD973F759EE; Mon, 2 Apr 2018 16:28:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40F3886133; Mon, 2 Apr 2018 16:28:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x243.google.com with SMTP id b5-v6so8681958itj.1; Mon, 02 Apr 2018 09:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=k0k16zOfogxI7Xlo3+BAvhMm3DTIneQ3I/r+MUxXoGo=; b=GlkkRG/+fFFFdmXb9n0kscxVtTMQDIXEwFQZuFfrxuugXChOiXFe7viGvhgd+WZ8HM zfxhhgvJ1RtHmCtjhxXtQo1l2mLFbP5QWA+a0WxqdlS4Aq6SNRnENFV9en+X7BNrFbjJ edb0mlUkBEYK57pclkhXRJATglCsZB+HYjsopusRuii+JwsO5jS902FthMR5u3Xv3qGT Hg/fv7hiNF7gqOurBb56JuBxCPLP5WtG6Jgo20pk1UX75Y6s+4x0IuGYP0Fv2ND8sC82 l3ZD07Y9WVjtXmzLqjZE/RV4eKpI6maW0mpcAvbNWwyEjJ3S9RI4BSvVnn2M6gBwTb2f rdLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=k0k16zOfogxI7Xlo3+BAvhMm3DTIneQ3I/r+MUxXoGo=; b=m5dhJmYMNAPQBVJt+/Et+K4I7AI4OA5vRGu5civwLJ3MTpHnCR+FI+Sbm/46G1f1wh IkXZMeiOkPt5tWbKX16jWsZ+uQ2XOm/rfgROmvufM1DtNwWlA9tQw8d/ZJRaW/Ck5l0B JJPhSo9Ix1YEDEqtjeFZQp7cztxvmAVGkWFzXfbeFDJ1hppu9NTIRujSn+Lo4XQ+oCn2 owz2GKZFm2y/fE37hcgGv/rtydm/FGTkX8VKTw4cvT2fy7CW06vynsl0ju5jLn9gZM4H /9CzDGXoDVn2ky4GRy/haPvuvpE7UKho+MNyuHPqnSiZMxTWhKSYgOY6iVzUMhgwd7GE +zQA== X-Gm-Message-State: ALQs6tCmeeVYHzrnwK7LUUrdeKEvDMCqpF/fHxjFWJrkDal00ElbG0WI UktT8xbhqzkC8XSe7GrPLHWzqT0d1o+4YKDkuQG65RiB X-Google-Smtp-Source: AIpwx49sIDI0N48wxlvvLfUP2JOetbHRuU+xns6jRGzZSs2bfq7TCkm3zViQGSTepe7qP1YST/FURYSWpCeh6Ok018Y= X-Received: by 2002:a24:a0c6:: with SMTP id o189-v6mr1630225ite.52.1522686488358; Mon, 02 Apr 2018 09:28:08 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.130.197 with HTTP; Mon, 2 Apr 2018 09:27:47 -0700 (PDT) In-Reply-To: <20180331184109.GA23589@lonesome.com> References: <201803311138.w2VBcKHP014025@repo.freebsd.org> <68DEEF9A-6290-40AD-B51D-E187593C089F@FreeBSD.org> <20180331131818.GA22697@lonesome.com> <20180331184109.GA23589@lonesome.com> From: Ed Maste Date: Mon, 2 Apr 2018 12:27:47 -0400 X-Google-Sender-Auth: LYvyMa4jMGZVNSCyBmnx2DnRTUY Message-ID: Subject: Re: svn commit: r331838 - in stable/11: . contrib/compiler-rt/include/sanitizer contrib/compiler-rt/include/xray contrib/compiler-rt/lib/BlocksRuntime contrib/compiler-rt/lib/asan contrib/compiler-rt/l... To: Mark Linimon Cc: Dimitry Andric , Antoine Brodin , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , re , svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-stable-11@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for only the 11-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 16:28:10 -0000 On 31 March 2018 at 14:41, Mark Linimon wrote: > > Number of ports with no maintainer: 4625 (16.5%) > > (that number is a bit stale) > > Add the number of port maintainers that are no longer active, overwhelmed > "group" maintainers, and the number of maintainers who only run -stable, > and you have a significant number. Do we have a good way of identifying maintainers who are no longer active? It's understandable that people, and especially volunteers, are going to get busy and may not be so responsive from time to time. On the other hand, it's unfortunate to repeatedly add weeks or months of latency if the maintainer is truly inactive. > Please also consider the fact that the _correct_ way to get patches like > this done is to submit them to the upstream (if it still exists) and get > them to incorporate them. That takes time, as well. I'd argue that the best way to handle cases like this is to develop a patch, ./configure change, workaround etc., simultaneously submitting upstream and committing to the ports tree. This way the port builds and is available for our users right away, upstream benefits from our work, and we don't need to carry a patch indefinitely (assuming upstream accepts it). An approach that relies on upstream accepting first the patch and then producing a new release I suspect is not viable given the variability in responsiveness of different upstreams. > Now let me add a personal irritation: no one has bothered doing a writeup > on "here's how you fix old broken code that no longer works." I am neither > a compiler expert nor a C++ expert -- I can sit around and twiddle knobs > and see if that makes things work, but that's not the type of commit I want > to make. (I have already been trying this with consolekit2, to absolutely > no result.) It's quite difficult to write that up in general, but one thing that is likely feasible is to identify and report common issues; I've tried to do that while working on the switch to lld as /usr/bin/ld - there are a small number of issues that come up with some regularity, and many that are unique. It's a lot harder to enumerate the failures that we'll see due to the compiler though, and the fixes or workarounds are also a lot more varied. > The folks that will suffer are the users who build their own packages, who > will find a large number of regressions with no warning. (e.g., there is > nothing in the ports UPDATING file yet.) Fair point, we should have an entry in UPDATING. > Please see the lld work that emaste has been doing for the type of thing > that makes working on ports a lot more bearable. My work's a bit of a different case though: I'm working to replace an existing and obsolete toolchain component that is not going to be upgraded, is on a deprecation path, and is relatively self-contained, so has different challenges and issues than a compiler upgrade. > tl;dr: this is the type of thing that needs coordination between various > teams. This is the most important point of this discussion: we do need to ensure there's good communication and coordination between teams where dependencies like this exist. I'll take the blame here: Dimitry asked me about merging the Clang update to stable/11 and I agreed that it was reasonable to merge sooner rather than later to have as much lead time as possible before the 11.2 process starts. I also assumed that outstanding Clang 6 issues in ports were farther along in being addressed. The key lesson from this discussion is that for significant commits and merges like this one we should make sure to always have sufficient advance notice.