Date: Sun, 01 Jan 2017 11:36:38 +0200 From: dan_partelly <dan_partelly@rdsor.ro> To: Mark Linimon <linimon@lonesome.com> Cc: Matthew Macy <mmacy@nextbsd.org>, <freebsd-x11@freebsd.org>, Beeblebrox <zaphod@berentweb.com> Subject: Re: End of year Xorg status rant Message-ID: <7dc8c4d9d9cdcb9bc0521d53cf94e04b@193.231.238.8> In-Reply-To: <20170101081136.GA5399@lonesome.com> References: <20161230163653.54909631@rsbsd.rsb> <15952279f17.e0be0d8c34357.732964216134709731@nextbsd.org> <20161231120453.13adf858@thor.walstatt.dynvpn.de> <20161231145143.18e6ac99@rsbsd.rsb> <1595742b65f.1050eb06862309.1096856657498598610@nextbsd.org> <20170101081136.GA5399@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 later 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 forms 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 contributors. 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 project. There are some side projects which should have never made it in the core OS 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 problem 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 think 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 which should be given priority. A modern init system to replaces the autoexec.bat style of OS initialization, a modern system wide notification bus like notifyd and a modern service management framework, one which allow easy management, introspection, fault management and fault reporting. For all the hate SystemD developers get, they did a great thing. Systemd might not be perfect, 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 now) 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 parts > 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 steeper > 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* heard > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7dc8c4d9d9cdcb9bc0521d53cf94e04b>