[Bug 239682] Default to devel/llvm90 when libLLVM/libclang are required or if /usr/bin/clang is not enough

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239682

--- Comment #27 from Warner Losh <imp at FreeBSD.org> ---
(In reply to Jan Beich from comment #25)
>(In reply to Warner Losh from comment #24)
>> when the llvm developers tell you it isn't ready, it isn't ready.
>Release happens when "the llvm developers" decide something "is ready" for wide >consumption.

No, FreeBSD decides when llvm is ready for FreeBSD.

>> When the graphics folks tell you it isn't ready, it isn't ready.
>Before you've started with FUD they were silent for the whole duration. x11@ was in CC >as requested in Mk/bsd.default-versions.mk.

It broke gnome. It broke other things. People don't always have time to try
things here.

>> If it's not ready, timing doesn't matter. Please start listening to your peers.
>Assignee decides when patch "is ready" to land. At the time there were no blockers and >maintainer timeout was reached. After landing all regressions were promptly fixed. I >don't think I've made any mistakes.

I think you have. I can't use gnome. I had to waste half a day to trouble shoot
it and switch over to LXDE.

>> Bland assertions that we need to do this,
>Assignee decides what work and how it's done. There were several issues (confusion and >blind spots) but it's a net positive. I'll try to do better in future.

Right. You didn't wait for the people in the project who spent lots of time
maintaining things to reply. In the past, we've not done big compiler bumps on
a 'timeout' basis. You didn't get a positive affirmation from Brooks, for
example. That's not cool. Even if there's technically a timeout rule, you have
to use some common sense around this and not do it on a 'timeout' basis.

>> or that a week is enough time are flat out wrong.
>2019-09-20 (landing) - 2019-08-06 (review request) = 45 days.

It was a week before the branch. And we knew *RIGHT*AWAY* things were broken.
And 9.0 hasn't been out for 45 days, so this is *BOGUS*.

>> This really needs to be backed out
>Why? I need a technical rationale.

You broke stuff. It's really that simple.

>> and you need to adopt a more conservative approach to pushing things in.
>Provide more details, including how to treat bad actors. My approach works fine >elsewhere i.e., wherever the graphics team is not involved.

Brooks isn't on the graphics team. People do not like your bull in a chinashop
approach. You have ignored the feedback and now claim it's OK except for the
graphics people? No, I don't buy it. And even so, if the graphics people are
complaining, it's on *YOU* to fix it. You are literally the only person I've
had to have more than a single conversation with due to problems created for
the graphics folks. 

>> You are literally making a lot of people very mad at you for not
>> listening to them.
>I'm awaiting brooks@ reply to shed light on what led to planning/prioritization >failure. Otherwise, it looks like a one-off misunderstanding.

It is not. There have been many complaints about you to over the past six
months.  I've not had success being nice, so I'm being firm now.

>> There's a lot of smart people in the project, and when they are mad
>> at you for how you've done something, it pays to listen. They are
>> almost certainly right.
>
>I do listen but don't blindly follow unless requested by the authority in charge. >"Smart people" is ambiguous term, those who excel at coding may not be good at >negotiating. Obviously, you have a lot more such experience but the current attitude >falls short.

My current attitude is because I'm sick to death of mopping up messes caused by
your lack of attention to detail and your lack of acknowledging that there's a
problem here to fix. My attitude is a direct result of prior attempts failing
to produce better behavior and at my wits end for knowing how to move forward.

-- 
You are receiving this mail because:
You are on the CC list for the bug.