Richard Brown wrote:
On 6 October 2016 at 23:37, Linda Walsh
wrote: Richard Brown wrote:
The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together.
First problem -- don't say it is the 'community' -- it's the "board" that makes the directions and allows those who wish to help that direction to work on creating the next distro.
The community, OTOH, submitted compatibility patches for various things (before systemd) in the past that were rejected, since the board choice was to disable the choice that could have been supported w/the patch. That story has been played again and again.
Linda,
Your above statement is absolutely unadulterated unquestionable baseless nonsense.
Those are my perceptions based on 10+ years of experience w/ SuSE/OpenSuse. That you wouldn't see things the same way, being on the "inside", is not surprising.
The Board's role is to provide guidance and decision making assistance when necessary, not to declare or force contributors to do anything.
I never saw discussions about accepting systemd or not on the opensuse or opensuse-factory lists. By the time I saw anything, I was told it was decided. As for patches -- I submitted patches for various products, but in specific, for one good example, with vim/gvim, I submitted a build patch for the rpm to allow the executable(s) to *attempt* to dynamically load the script languages at runtime, and dynamically configure available script options based on what was able to be included (as it does on Windows). This was after being in repair mode, trying to run vim but being told it wouldn't run because it couldn't find libs for various languages (ruby, python, perl) so it couldn't "edit" any files. ??? I didn't need to run scripts -- I wanted to edit the files -- but the vim builder had hard-linked all the script engines in to require them present at runtime -- in ORDER to edit files. Similarly I tried to submit support for building perl without lots of version requirements so vim could try to load the current perl (if it failed, no perl support) -- as it used to be able to before someone got very nit-picky to not even allow different "patch-level" releases of perl to be loaded or used in place of an early perl of the same major-minor version. I even provided statements from the perl developers that the patch-level versions were designed to be compatible so people could update a bug in perl without having to recompile®enerate all the modules for a specific major-minor perl. But the suse builder refused, pretty much running around talking about how the the sky would be falling if that was allowed. Pleh! I'd done it for 4-5 years in suse before that with no problems, now due to version hell, I havn't had many components of yast running since 12.3. yast to run.
The openSUSE Board is strict and strong believers in the principle of "Those Who Do, Decide",
--- And there's the rub -- Who is allowed to "DO". It's a cute saying, but when who is allowed to "Do" is controlled, the whole thing becomes a different way of controlling what is done and what is decided. In a similar way, one of our worst presidents in history, George Bush II, fired all government employees who couldn't be verified to be loyal Republicans. Such had never been done in recent memory, and threw away scores of decades of experience by firing career employees who had been at their jobs through many presidents. By only allowing Republicans in government offices (including the federal courts), they could ensure only decisions favorable to the party's political views would be made. I couldn't even get a OBS account to work and was finally told I should create and register a new email to get a new account and try to set it up again, as the old one was broken (and no one knew how to fix it).
Therefore, you cannot argue that "The Board" makes those decisions. The openSUSE contributors decide the direction of this project. Full stop.
I can argue it, as the board approves who it lets volunteer and do the work. In a similar way Bush-II had control far beyond his direct-influence or power.
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
you might, but the board wouldn't.
I saw previous, similar decisions with hoping to XFS for all disks, then not supporting it due to a hop to grub which had a bug on XFS (vs. staying with lilo which didn't show the bug). Or not supporting lilo -- even when the version from the developer still worked, or not supporting direct-boot from disk -- which is still working for me even with separate root+usr, which I was told wouldn't work and wouldn't be supported, even though it is recommended in systemd documentation for better performance. When I asked for reasons why it was required to create unstable forward-symlinks (forward to partitions that hadn't been mounted yet) in /bin to /usr/bin, vs. the *safer* alternative of putting the binaries in /bin and back-links in /usr/bin to it's parent fs where /usr is mounted. I was told it was already decided by the "doers" and couldn't be fixed and wouldn't be done. When I asked why /usr couldn't be mounted in early boot (S01boot.usr-mount) to make sure /usr was available for other boot & starting services that needed it, I was told it couldn't be done (yet that is how my system is running). I've had tons of such experiences to show me how open Suse really is, to say that it's simply "not true" is ignoring the many times Suse has been closed because the "ship has sailed around the world N times... etc".. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org