llvm90 -why

[Jan Beich]

Warner Losh <imp at bsdimp.com> writes:

> On Sun, Sep 22, 2019 at 12:50 PM Jan Beich <jbeich at freebsd.org> wrote:
>
>> Vasily Postnicov <shamaz.mazum at gmail.com> writes:
>>
>> > вс, 22 сент. 2019 г., 13:25 ajtiM via freebsd-x11 <
>> freebsd-x11 at freebsd.org>:
>> >
>> >> On Sun, 22 Sep 2019 12:22:21 +0200
>> >> Jan Beich <jbeich at FreeBSD.org> wrote:
>> >>
>> >> > ajtiM via freebsd-x11 <freebsd-x11 at 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 one
>> >> > > 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 this,
> 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 kind
> 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 230789.

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.