"DRM removal soon" is premature

[Johannes Lundberg]

On 2/14/19 11:30 PM, Steve Kargl wrote:
> On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
>> Not to pile on unnecessarily here, but I think the fundamental issue is that
>> there is nobody who wants to maintain the in-tree DRM, and removal is likely a
>> better option to half-assed maintenance. I'd imagine there'd be a different
>> discussion if several developers were clamoring to keep this driver well
>> maintained in the tree.
>>
> Unhooking a driver from the build, so that it cannot expose
> a change that breaks said driver is certainly a way to 
> ensure the driver is not maintained.
>
> Wasted a weekend trying to find and attempting to fix the
> damage caused by a change in src/sys to the drm-legacy-kmod
> port.  You know, the port that was promised as part of the
> drm2 removal.  I would have spent this weekend testing 
> changes to cexp, cexpf, the soon-to-be-submitted cexpl,
> ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
> all on hold now as I'm not sure when I'll be able to carve
> out time for testing.

This happens all time for me with virtualbox-kmod as well in current.
Changes to src breaks certain (kmod) ports and there's always a delay
until they are fixed. This is life in -CURRENT. I accept this and don't
go bitching to virtualbox-kmod maintainers about it. Your usage is an
edge case so naturally there will be a longer delay before breakage is
noticed, until we can get automated CI up and running (even so, there
will be a delay).

With graphics, there's a software fallback (vesa/scfb), virtualbox has
no such option.

For stable usage, there are -RELEASE options.