Mailinglist Archive: opensuse (856 mails)

< Previous Next >
[opensuse] Re: interesting reading about systemd
  • From: Richard Brown <RBrownCCB@xxxxxxxxxxxx>
  • Date: Sat, 8 Oct 2016 23:54:20 +0200
  • Message-id: <CAA0b23yAwO1bqhhJ_6qpNPLbtdwYK6rPK_5VzTw3bPOKca=XSw@mail.gmail.com>
On 8 October 2016 at 22:31, L. A. Walsh <suse@xxxxxxxxx> wrote:

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.

I remember them

They were very long

They also included debates at conferences like openSUSE Conference 2010 and 2011

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&regenerate
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.

None of the above examples were anything to do with the Board

All of the above examples sound like you were doing stuff with the
primary maintainer wouldn't want to accept for very good reasons.
If you disputed those reasons you should have discussed them with the
maintainer at length at first, maybe discussed it in a broader context
next and then perhaps escalated the topic TO the Board
Blaming them for something they had nothing to do with just paints a
picture of you as someone who has no idea how the openSUSE Project
works despite your 10 years of activity with the project.






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.

Politics have no place here. I consider your analogy as both baseless
and offensive, and kindly request to stick to our guiding principles
and avoid being so in the future.


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).

The Board also had nothing to do with this

Do you have the ticket number for your support call with our infra
team (admin@xxxxxxxxxxxx) regarding your account issues?


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.

Ok, you can argue.

You are wrong.

The Board does not appoint maintainers.

The Board does not approve volunteers.

The people doing the work, are the people doing the work, the ones who
have stepped up and posted on opensuse-factory and said "I will take
the responsibility for $foo" and then poured their efforts behind that
commitment

The Board has no say in such matters, it's a simple case of "if no one
else is taking care of it, thanks, you're it!" and if someone else is
taking care of it then the expectation is that the parties involve
find a way to work together (and only if they can not, is there the
possibility that the Board might end up involved to resolve that
conflict between contributors).




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.

Yes, people doing more work for you, who are actively maintaining more
parts of the distribution, are going to have more influence on the
technical decision of the project..that is the very essence of "Those
who do, decide"

"I did this one small thing so I get to decide despite the impact that
has" is not a valid operational mantra of the openSUSE Project.

The lesson I think you need to take away from this thread is that
"doing" does not include mailinglist posts. I have long seen you on
our lists and I know you have submitted things from time to time, but
I have never seen you step up and take responsibility for any part of
the openSUSE distribution, to effectively 'own' something as part of
our community project, and to do all that such entails, such as taking
the initiative, driving the effort, and working with others to make
everything work together.

sysvinit could have been that thing, it could have been it back in
2010, it could still be it now (admittedly with more work for you).
But if you don't do the work, we're just going to be wasting our
breaths and electrons on this mailinglist.

If you only ever throw stones over the wall, either in the form of
drive-by patches or grumpy mailinglist posts, you need to expect those
stones to be thrown back.

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread