From owner-svn-src-stable@freebsd.org Sat Mar 31 18:41:13 2018 Return-Path: Delivered-To: svn-src-stable@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 C45DFF770A6; Sat, 31 Mar 2018 18:41:13 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6053C70862; Sat, 31 Mar 2018 18:41:13 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 0AB52284D; Sat, 31 Mar 2018 13:41:11 -0500 (CDT) Date: Sat, 31 Mar 2018 13:41:09 -0500 From: Mark Linimon To: Dimitry Andric Cc: Antoine Brodin , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , re , svn-src-stable-11@freebsd.org 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... Message-ID: <20180331184109.GA23589@lonesome.com> References: <201803311138.w2VBcKHP014025@repo.freebsd.org> <68DEEF9A-6290-40AD-B51D-E187593C089F@FreeBSD.org> <20180331131818.GA22697@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 18:41:14 -0000 On Sat, Mar 31, 2018 at 06:44:01PM +0200, Dimitry Andric wrote: > I am very disappointed that it apparently takes more than 3 months > (half the lifecycle of a complete upstream llvm release!) to fix > broken ports. Don't maintainers read their email, or care about > their ports? 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. Like any task, this needs someone to step up and coordinate so that the work is getting done. Thinking that it will automagically happen is unrealistic. 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. This is an immense codebase, constantly changing. 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.) > In fact, I thought this was the perfect timing, so that the quarterlies > are built with clang 6, and it has enough time to settle for the 11.2 > slush. The quarterlies won't be build from clang 6. They are always based on the oldest supported point release per branch. 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.) Please see the lld work that emaste has been doing for the type of thing that makes working on ports a lot more bearable. tl;dr: this is the type of thing that needs coordination between various teams. mcl