llvm90 -why

[Warner Losh]

On Sun, Sep 22, 2019, 2:23 PM Jan Beich <jbeich at freebsd.org> wrote:

> 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.
>

Time of filing is irrelevant.  And things were broken.

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.
>

That is a matter of opinion. And the past 20 years of my experience has
shown it's a bad plan.

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.
>

Oh give me a break. You did a drive by outside the normal channels. That is
the uncool behavior. This isn't hazing you. This is telling you that this
drive by steps on people's toes. It creates an urgent crisis for them that
didn't exist before your commit. The implicit demand is to drop everything
and clean up YOUR mess. That's not hazing on our part, but disrespect of
our time on your part.

Warner