Date: Sun, 22 Sep 2019 14:22:58 +0200 From: Jan Beich <jbeich@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD X11 <x11@freebsd.org> Subject: Re: llvm90 -why Message-ID: <woe0-a5b1-wny@FreeBSD.org> In-Reply-To: <CANCZdfr-4aRAC4==-Dcy8hFgWgkGuADp9URArnutjJBWajzRMA@mail.gmail.com> (Warner Losh's message of "Sun, 22 Sep 2019 13:13:20 %2B0200") References: <20190922051624.4a628733@dismail.de> <h854-iqaq-wny@FreeBSD.org> <20190922102528.63ab9df0@dismail.de> <CADnZ6BnuX=sE_53-9bVLqga4XEznj8mYUf5QDBVsx=XCciRV%2BA@mail.gmail.com> <zhiw-haes-wny@FreeBSD.org> <CANCZdfr-4aRAC4==-Dcy8hFgWgkGuADp9URArnutjJBWajzRMA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@bsdimp.com> writes: > On Sun, Sep 22, 2019 at 12:50 PM Jan Beich <jbeich@freebsd.org> wrote: > >> Vasily Postnicov <shamaz.mazum@gmail.com> writes: >> >> > =D0=B2=D1=81, 22 =D1=81=D0=B5=D0=BD=D1=82. 2019 =D0=B3., 13:25 ajtiM v= ia freebsd-x11 < >> freebsd-x11@freebsd.org>: >> > >> >> On Sun, 22 Sep 2019 12:22:21 +0200 >> >> Jan Beich <jbeich@FreeBSD.org> wrote: >> >> >> >> > ajtiM via freebsd-x11 <freebsd-x11@freebsd.org> writes: >> >> > >> >> > > Hi! >> >> > > >> >> > > Mesa-dri is updated and needs llvm90. It is okay. But libosmesa >> >> > > needs llvm80. Now I have llvm60, llvm80 and llvm90 and and each o= ne >> >> > > needs a lot of time to build. >> >> > > >> >> > > pkg info -r llvm80 >> >> > > llvm80-8.0.1.: >> >> > > libosmesa >> >> > >> >> > I didn't notice, and poudriere doesn't catch such issues. >> >> > Fixed in https://svnweb.freebsd.org/changeset/ports/512572 >> >> >> >> Thank you. >> > >> > What's worse, lang/clover was not updated and still seems to require >> > llvm80, but devel/libclc now depends on llvm90. This breaks OpenCL on = amd >> > cards completely >> >> lang/clover doesn't build with llvm90, see >> https://reviews.freebsd.org/P294 >> I'm relying on users' feedback as the maintainer didn't help test bug >> 239682. >> >> Can you document OpenCL error for posterity? >> > > The week before quarterly branch is the wrong time to do changes like thi= s, > especially since there's now collateral damage that needs to be mopped up > by many other people who have not planned the time for the work. This is > quite disrespectful of their time and boarders on abuse. Please consider > this more carefully in the future. You do good technical work, but failing > to manage the social aspects of it is causing too much friction of the ki= nd > that (a) can be avoided and (b) tends to drive people away (hence my abuse > comment). Bug 239682 was filed ~1.5 months ago. It was part of my dogfood: tested via poudriere on all release/architecture tuples. Only x11@ wasn't ready. I'm happy to kick x11@ from LLVM_DEFAULT train per the promise in bug 23078= 9. The time of landing was planned in advance. 1 week is enough to fix loose ends in ports/. /quarterly branches are not frozen, regression fixes can be backported if necessary. And I'm not running away from regressions. It's the same workflow I use when updating ports with hundreds of consumers e.g., boost, ffmpeg, icu. As for "social aspects" I'm not a friend but a fellow contributor. Document rules/policies properly. If one relies on stuff discussed behind closed doors it's no different from hazing i.e., doesn't belong in an open project.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?woe0-a5b1-wny>