Hi Leonid, Leonid Bobrov wrote on Mon, Jul 01, 2019 at 07:41:41PM +0300:
> No, you three (...) are wrong, I doesn't matter who is wrong, please stop discussing that. What matters is that code gets written, tested, improved, and eventually committed that improves the situation. > protecting a bloat called X. Well, i did happen to do some minor work on Xenocara lately, even if it was only related to documentation. The reason we maintain Xenocara is not that everybody loves it so much. There is indeed consensus that it suffers from considerable design flaws. The reason we maintain it is that, if you want to make something better, the better solution must be fully implemented, tested, and committed before the old system can be removed. I have no idea which steps exactly are involved in that, and whether and how it is feasible, but it is blatantly obvious we are very far from the point where deleting Xenocara could possibly be considered. Either way, i'm very thankful for matthieu@, jsg@, and others maintaining Xenocara and the related kernel parts *because they manage to keep that stuff surprisingly reliable and functional* given how complicated it all is. > The only thing we miss for Wayland in base is libxml and it's not > as bloated as shit called DRM, Mesa and X.org, so it's perfectly > acceptable, Frankly, there is not much point in non-developers discussing whether additions to base are acceptable. Feel free to suggest specific patches for base, but when developers voice doubts, save yourself a lot of trouble and organize your work as a port instead. It is *much, much* easier to get something into ports, and to get it tested there, than to get something into base. Getting something into base is often a challenging task even for an experienced developer. Also, getting something into base is easier when a long-standing, well-tested port already exists. > Juan, if you help me Wait a second, juanfra@ is a prolific porter who is already contributing a lot to OpenBSD. Like every developer, he is free to choose what he wants to work on. > with wscons then we can have working Wayland > compositors running outside of X session in 2019 at OpenBSD. You might have a point that ws*(4) and ws*(9) documentation could possibly be improved - i'm not completely sure, but i dimly remember running into problems trying to use features of these systems in the past. Consider reading the ws* code and figuring out what exactly it does, then sending patches to improve the documentation. That is how documentation gets better: people reading the code, understanding, and describing it. And everybody, please stop sending messages if you have nothing new to say that is of substance. The usefulness of this thread has somewhat lessened of late. Yours, Ingo
