Re: drm / drm2 removal in 12

Hi Owen -
I understand that you're enthusiastic and you just want what's best for the
project. However, there's a couple of points I hope you'll take to heart.
First, please read what you sent and think about the tone and word choice.
It's extremely negative and critical - you're actively alienating people on
the list. You're not going to be successful engaging any open source
community or workplace if you choose to communicate like this. Second, this
is a volunteer project. One needs to establish a track record of producing
patches and working with developers to get them committed. Regardless of
how sound your technical position is - you're going to have a hard time
being acknowledged if there is no contribution to match.

Best wishes.
-M


On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme <gurenchan_at_gmail.com> wrote:

>
>
> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh <imp_at_bsdimp.com> wrote:
>
>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy <mmacy_at_freebsd.org> wrote:
>>
>> > On Fri, Aug 24, 2018 at 14:53 Ali <aliovx_at_gmail.com> wrote:
>> >
>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
>> > > > Just in case anyone misses the change to UPDATING:
>> > > >
>> > > > 20180821:
>> > > >         drm and drm2 have been removed. Users on powerpc, 32-bit
>> > > hardware,
>> > > >         or with GPUs predating Radeon and i915 will need to install
>> the
>> > > >         graphics/drm-legacy-kmod. All other users should be able to
>> use
>> > > >         one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
>> > > >         graphics/drm-next-kmod, graphics/drm-devel-kmod.
>> > > > Note that this applies only to 12.
>> > >
>> > > I see that The removal of drm and drm2 has been reverted on svn. Could
>> > > you please kindly share the reasons behind the re-inclusion?
>> > >
>> >
>> >
>> > I can’t really give the blow by blow of internal project drama, but the
>> > gist of it is that “best practices” (which are not yet actually
>> documented
>> > anywhere that I’ve seen) were not followed with regards to the
>> deprecation
>> > process. Warner and others believe that we can address the objectives of
>> > the drm removal (improving the user experience and communicating that
>> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
>> > through less disruptive means.
>> >
>>
>> Just so.
>>
>> Our only continued frustration is that we were never given any guidance by
>> > RE or core on said “best practices” when the discussion was taking
>> place in
>> > May and then those groups behaved as if this were a surprise when the
>> > removal happened. I’m cautiously optimistic that this well expedite
>> > improving communications on those matters.
>> >
>>
>> All the problems that are exposed by this aren't technical. This one is
>> social, but no less important.
>>
>> Warner
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org
>> "
>>
>
> I've been watching this debacle for quite some time now and I'd just like
> to ask why the rush?
>
> The graphics team is working very hard to destroy the stability of FreeBSD
> just so that they can force their uncooked work down users throats.
>
> The Linuxkpi is unstable at best, alpha level software that's constantly
> in need of someone to go and fix something on FreeBSD because Linux devs
> decided to make some changes or implement a new feature.
>
> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> Goals
>
>    - Move DRM headers to a similar location as Linux
>    -
>
>    Use kmalloc() instead of malloc(9)
>    - Use kref
>    -
>
>    Use idr and get rid of drm_gem_names.c
>    - Use PCI API
>    - Use Linux locking primitives
>
> is garbage, if you want to use develop Linux code and use Linux then go do
> that on Linux.
>
> Are these guys insane and please avoid the nonsense about you're doing
> this in your spare time.
>
> If you cannot devote the resources to do something right then don't do it
> at all.
>
> Keep that stuff in to yourself or anyone crazy enough to follow those
> steps to get it up and running, you guys cannot expect to contaminate the
> entire FreeBSD project for this mess.
>
> This is nonsense and I hope that more people who see it as such would say
> so and stop having these guys forcing this crap; it's maintenance hell who
> will maintain it if they decide to leave?
>
> Best,
> Owen
>
>