Date: Fri, 04 Oct 2019 15:55:05 +0000 From: bugzilla-noreply@freebsd.org To: gecko@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-21738-rLz1ld0krY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-239682-21738@https.bugs.freebsd.org/bugzilla/> References: <bug-239682-21738@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 #25 from Jan Beich <jbeich@FreeBSD.org> --- (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. > 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. > 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. > 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. > or that a week is enough time are flat out wrong. 2019-09-20 (landing) - 2019-08-06 (review request) =3D 45 days. > This really needs to be backed out Why? I need a technical rationale. > 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. > 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/prioritiza= tion failure. Otherwise, it looks like a one-off misunderstanding. > 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. --=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-21738-rLz1ld0krY>