RFC: adding fd-passing to win32

[David Rheinsberg]

On Sun, 21 Aug 2022 at 23:38, Thiago Macieira <thiago at kde.org> wrote:
> [...] The passage you're
> quoting from me was pointing out that the path he is choosing seems to me to
> be more difficult than the other, in particular because it requires a review
> from very busy people who have little knowledge about Windows and less
> interest in it.

But this behavior is exactly what I am criticizing. In my opinion,
stating that maintainers are "very busy people" and have "less
interest" in a supported target does not encourage contribution, nor
does it establish a welcoming community. It creates a wall between
contributor and maintainer and gives the impression that the
maintainers of the projects do not appreciate being addressed. It
enforces hierarchy, where there is no need for it.

> > Why do we shower contributors in CVEs when they ask whether something
> > was problematic? Bugs happen, security problems happen, how is this a
> > good explanation for something being "problematic"? If it was
> > problematic, can't we tell them why, rather than showing the bugs _our
> > implementation_ had? CVE-2014-3635 is literally about a buffer
> > overflow, how is this relevant other than accidentally being in the
> > code that handles fd-passing?
>
> Because modifying D-Bus and fd-passing requires a lot of specialised knowledge
> to write the code and review it, to make sure we don't create more or
> reintroduce old security issues. Those were meant as examples of why such a
> thing is not trivial and to support the suggestion of taking the path of
> minimal change (implied here the assumption that the minimal change is also
> the one least likely to introduce problems).

But this is true for any code. My criticism was that telling people
change is troublesome will deter them from contributing. What is the
point of collaboration if we do not appreciate the troubles of change?

I do not question the technical correctness of the replies, but rather
the tone and setting, and the effect on contributions.

> > Why can't we encourage contributors more? Why can't we be more
> > welcoming, assisting? Tell them we acknowledge their work, and we
> > appreciate it? And if we don't have the time for welcoming
> > communication, why not just refrain from commenting at all?
>
> Like the three months that passed between the two original emails and my reply
> that offered any hope of the change being accepted at all? Before I replied, it
> was dead in the water.
>
> I kept those two emails unread in the "dbus" folder for months because I
> thought it deserved a worthwhile effort on my part to reply. I could have just
> ignored them.
>
> Should I just not reply at all to any suggestions?

I think a lack of replies would have been a more honest representation
of the current state of D-Bus development, yes. The answers and delays
in this thread show that the current maintainers of D-Bus are very
busy and have less interest in such contributions. Moreover, it
discourages readers from submitting further contributions to D-Bus. A
lack of replies to this thread would have shown the state of D-Bus
development equally well without the negativity towards contributors.

I do not intend to tell you what to do. However, as maintainer of
dbus-broker I feel inclined to let upstream D-Bus know why we are
having a hard time sharing our efforts with you, and connecting our
communities together more. You are welcome to disagree and run your
community channels your way.

Thanks
David