llvm90 -why

[Jan Beich]

Warner Losh <imp at bsdimp.com> writes:

> 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 bug filing was a formal request for feedback, review and testing.
Ports expected to remain broken were quickly capped at llvm80.

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

Maybe in src/ but in ports/ things move at far faster pace. In that
respect Mesa ports are relatively minor and only impact desktop.

Do you consider how long it took for bug 230789 to land as normal?
No other team in ports/ works as slow as x11 at . Do you consider
how bug 217635 was treated as normal? No other team is as militant
about changes as x11@, especially when maintainer cannot test runtime.

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

Bugzilla is outside? In ports/? When bugs are CC'd to the mailing list?
Unlike the graphics team I make a principle to avoid discussions behind
closed doors as it'd be disrespectful to other contributors.

> That is the uncool behavior. This isn't hazing you. This is telling
> you that this drive by steps on people's toes.

In ports/ it's often impossible to avoid stepping on someone's toes.
That's precisely why ports/ have a policy of "portmgr blanket" and
"maintainer timeout" i.e., no exclusive ownership.

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

Fixing regressions is the responsibility of those who introduced them.
Relax and let me deal with those.

If one need to "drop everything" after some changes it's prime example
of the code being in such a poor shape that one can't trust anyone else.
In other words, it reflects on maintainer doing a bad job of documenting
workflow/code/etc. or mentoring new contributors. And mentoring cannot
happen if maintainer's feedback is very slow.

As for "disrespect" I find it ironic how you care only about your time
but not mine. Waiting on someone is not free, it requires allocating
time to deal with feedback in a prompt manner. This is why ports/
have "maintainer timeout" policy, so no one feels offended.