Please revert unapproved commit to x11-wm/fvwm3

From: Felix Palmen <felix_at_palmen-it.de>
Date: Tue, 19 Jul 2022 13:22:16 UTC
I'm maintaining a few ports in my spare time. I do my best to help
people running into issues with them, on the forums, lists, bugzilla,
...

Now, please refer to <https://bugs.freebsd.org/265291>. This is about a
crash I can't reproduce myself, and it *looks* like some UB is causing
it.

When my feedback as a maintainer is requested via maintainer-feedback?,
I set it to maintainer-feedback+ as soon as I provide that feedback.
Actually, that's what's documented for that flag:

| * Set (+) when you provide feedback. Avoids "maintainer timeout"
|   (MAINTAINER)

I really don't need any "maintainer timeout" to hit me while trying to
fix problems.

For a crash you can't reproduce yourself, it makes a lot of sense to
provide a test patch for the reporter to test, so you know for sure this
fixes the problem. I attached such a patch, the reporter promised to
test it soon, and of course I didn't set any maintainer-approval flag on
it.

Now, this is committed nevertheless. By someone insisting
maintainer-feedback+ would mean approval of a patch, which it doesn't.
For this, plase also refer to
<https://wiki.freebsd.org/Bugzilla/DosAndDonts>:
| DON'T use maintainer-feedback flag to declare approval of a patch. (DO
| use the maintainer-approval flag)

The commit *might* be correct, this patch *might* fix the problem. But I
really don't want it committed before I can be sure. As a maintainer, I
must stay in control of such things, and not be overruled by someone who
wants to force their false asssumptions about the meaning of the flags
upon me.

Doing maintainer work that way is just frustrating.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A