Date: Mon, 2 Apr 2018 12:27:47 -0400 From: Ed Maste <emaste@freebsd.org> To: Mark Linimon <linimon@lonesome.com> Cc: Dimitry Andric <dim@freebsd.org>, Antoine Brodin <antoine@freebsd.org>, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, re <re@freebsd.org>, 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: <CAPyFy2DL3Acp6DanoZBZm57XWhiujtM0os9Yau6spe%2Bhdzn8Gg@mail.gmail.com> In-Reply-To: <20180331184109.GA23589@lonesome.com> References: <201803311138.w2VBcKHP014025@repo.freebsd.org> <CAALwa8mB-FWA%2B_tKXO19x%2B9_CKy6%2B80vxqbKieEXY9fre1ZPdg@mail.gmail.com> <68DEEF9A-6290-40AD-B51D-E187593C089F@FreeBSD.org> <20180331131818.GA22697@lonesome.com> <EF4245AC-5D9B-44AE-B4A4-B2A9A52FCA1B@FreeBSD.org> <20180331184109.GA23589@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 March 2018 at 14:41, Mark Linimon <linimon@lonesome.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2DL3Acp6DanoZBZm57XWhiujtM0os9Yau6spe%2Bhdzn8Gg>