your mail

[Emil Velikov]

On 22 February 2017 at 14:46, Matthew Rezny <rezny at freebsd.org> wrote:
> On Wednesday 22 February 2017 14:36:36 Emil Velikov wrote:
>> On 22 February 2017 at 12:08, Baptiste Daroussin <bapt at freebsd.org> wrote:
>> > On Wed, Feb 22, 2017 at 12:00:58PM +0000, Emil Velikov wrote:
>> >> Hi gents,
>> >>
>> >>
>> >> My name is Emil Velikov and for a while I've been taking care of
>> >> libdrm and Mesa.
>> >>
>> >> I can see that there is some activity on the above in FreeBSD so I'll
>> >> kindly ask that you send [every and any] changes upstream ;-)
>> >> Please try to keep different [logical] changes into separate patches
>> >> and git send-email them to the mailing lists [1] [2].
>> >>
>> >> This includes [but not limited to] the prefix fix for drirc, \< and
>> >> shebang workarounds in [3]. But also covers `sed s|x86_64|amd64|'
>> >> "GNU_CONFIGURE = yes" and various USES [gmake, bison, python etc.]
>> >>
>> >> In a gist, things should just work:
>> >>  - no need for gnumake - any POSIX make should work
>> >>  - flex/bison/python/etc are not needed when building from tarballs
>> >>
>> >> If you need to patch and/or add _any_ workaround in your Makefile,
>> >> please file a bug and let us/me know.
>> >>
>> >>
>> >> Finally, I would like to invite you (maybe subscribe x11 at FreeBSD.org
>> >> ?) to the [4] list.
>> >> It's very low volume and covers topics for maintainers' eyes. Most
>> >> recent of which "pthread-stubs design is broken" [5].
>> >
>> > First thank you for contacting us.
>> > Yes upstreaming as always been the plan. We still have to first make up
>> > our mind on how we deal with the libudev dependency either through our
>> > home baked equivalent or via a heavily modified libudev
>>
>> With Mesa 13.0.0 the triple libudev/sysfs/libdrm codepaths were
>> merged. I've pulled a helper to libdrm to deal with that.
>> Personally I'd suggest keeping all the chaos in there.
>>
> As of Mesa 13 we do let libdrm handle that (no more patches to Mesa for it),
> but we are patching in support for libdevq, a minimal alternative to libudev.
> Now that we also have libudev-devd, a partial implementation of libudev atop
> devd, we need to reconsider libdevq's existence.
>
Merely pointing out that there should be no reason why to have any
such platform specifics in Mesa. If something does flag up - shout !

>> For 17.0.0 we also removed the --with-sha1 'fun' heuristics. That and
>> more can be found on the mesa-maintainers@ ;-)
>>
>> > In the meantime we can work on upstreaming all other parts :)
>>
>> Yes, please.
>>
> It has been my intent to upstream as much as possible, but I was trying to get
> us caught up to current before doing so. No point in submitting a patch for a
> section of code that may be gone in the next version after all. Differences in
> build system is lower priority, top will be the patches that were required to
> avoid compiler errors (several bits in clover did not compile on any version
> of LLVM/Clang I tried without patching), which should be reviewed.
>
You really do not want to waste time doing the same work multiple times :-)

Just send anything and everything as soon as possible - even alongside
the initial FreeBSD submission, please ?
Otherwise BSD (in general) will never get out of this constant game of chase.

Fwiw I'm looking at some of the shebang stuff atm - most/all of that
is dead code and I'll just nuke it ;-)

Thanks
Emil