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...

[Mark Linimon]

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