Date: Fri, 04 Oct 2019 16:09:32 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 239682] Default to devel/llvm90 when libLLVM/libclang are required or if /usr/bin/clang is not enough Message-ID: <bug-239682-7141-R8dsBWvZwQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-239682-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-239682-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239682 --- Comment #27 from Warner Losh <imp@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. x1= 1@ 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 s= hoot 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 (c= onfusion and >blind spots) but it's a net positive. I'll try to do better i= n 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 h= ave 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) =3D 45 days. It was a week before the branch. And we knew *RIGHT*AWAY* things were broke= n. 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 chinas= hop 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.=20 >> 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/prioritiz= ation >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 no= t be good at >negotiating. Obviously, you have a lot more such experience b= ut the current attitude >falls short. My current attitude is because I'm sick to death of mopping up messes cause= d 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 faili= ng to produce better behavior and at my wits end for knowing how to move forwa= rd. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239682-7141-R8dsBWvZwQ>