End of year Xorg status rant

dan_partelly dan_partelly at rdsor.ro
Sun Jan 1 09:42:26 UTC 2017

> And this is the key point: we need more committers.

With all due respect, you guys need to take more seriously the process 
and politics of contributions to FreeBSD. Especially the core, they should
make this a priority. 

> If the folks in this thread (and the similar one about numerical
> computation) saying "someone should do something!" worked towards being
> committers, we would all be better off.

Too what end ? I myself had a small contribution to the project, it sit 
close to 5 months in a differential form until Pedro looked at it, and
Adrian Chad said it is ok with it as well. I have more patches, but Im not

extremely motivated up them for review. I will some day.  The time frame
for review 
is way too big to keep anyone interested. There are patches in various
which address some  issues of the OS (or at least tries to address them,
but a 
discussion on them  is warranted) which languish in limbo with *years*. 

Frankly, at this point, I look at "We need more committers" as empty 
rethorics. For it doesn't seem you guys do much to attract new
It is a personal opinion, of course, nevertheless it is what I see. 

There is also something which I perceive as a lack of direction in the
There are some side projects which should have never made it in the core
in my opinion. Case in point, libxo integration experiment (and all 4 or 5
user-land utilities which where converted to use it. Someone from the core

should take a long look at such projects. Questions to ask for example

- what is the problem the change wants to solve ? 
- once the problem is identified, ask if the change really solves the
  as opposed to being some unnecessary distasteful hack. (i.e libxo vs
  libification of core OS utils so anyone can write easily their utils 
  and even integrate libxo in them if they want)
- is it necessary that this change is part of the OS, or would it be much
   better to keep it as a port ?
- and if it should be part of the OS, should it be part of the OS (I seen
  a slide from a FreeBSD developer conference where somebody wanted 
   libxo in the kernel. Even the fact that somebody had the audacity to
   at that made me tremble with angst. 
- is it useful to OS users in general, or supports only a corner use case
- is it orthogonal to the rest of OS features ?
- is the implementation team committed to propagate the change to the
entirety of 
the OS ? As opposed to 5 utils only, and let the rest rot in oblivion.
- does it complicates system administration? Does it simply it ?

> What frustrates me is that people don't understand that the players I
> know within FreeBSD *want* to have better graphics.

Yes, I want better graphics too. I run OSx now on my laptop, but Id rather
have FreeBSD on it, save graphics state and out of the box ACPI & power 
management state. 

>>Finally, I do know of at least one person within FreeBSD whose stated
>> goal is to Make This Integration Happen in 2017.

An awesome goal.  There are also some other  extremely important changes
should be given priority. A modern init  system to replaces the
style of OS initialization, a modern system wide notification bus like
and a modern service management  framework, one which allow easy
introspection, fault management and fault reporting. For all the hate 
SystemD developers get, they did a great thing. Systemd might not be
might overstep its boundaries in some places, but it is light years ahead
the 45 years old init systems FreeBSD uses. 

Hopefully, FreeBSD will see the value of Jordan Hubbard and M. Macy work
on trying to make those things happen. For without them, there isn't much 
future left, except for vendors who will take FreeBSD and mold it with 
their money in exactly what they want (Sony and Juniper come to my mind
and never contribute back anything meaningful, which would help the 
OS in a significant way.

> And, no, I don't believe that process is easy.
> But what people don't appreciate is that the large number of moving
> in the Ports Collection (times 7? architectures, times 4^W3 release
> branches)
> creates something intricate.  There's a learning curve to being able to
> commit something that doesn't break anything else; the curve gets
> the closer you get to the center of the infrastructure.
> And this work is pretty close to the center.
> (And never mind about trying to make all of that robust and consistent.)
> What frustrates me is that people don't understand that the players I
> know within FreeBSD *want* to have better graphics.  I have *never*
> anyone say "just walk away from it".  It's a question of how we can get
> there with the limited manpower we have available.
> Finally, I do know of at least one person within FreeBSD whose stated
> goal is to Make This Integration Happen in 2017.
> But I'm not crazy enough to think it is going to happen this week.
> mcl
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"

More information about the freebsd-x11 mailing list