From: Ingo Schwarze <schwarze@usta.de>
Subject: Re: ksh vi mode: stop 'P' command from moving the cursor
To: Walter Alejandro Iglesias <wai@roquesor.com>
Cc: tech@openbsd.org
Date: Wed, 23 Apr 2025 17:17:10 +0200

Hello Walter,

Walter Alejandro Iglesias wrote on Wed, Apr 23, 2025 at 11:01:14AM +0200:
> On Tue, Apr 22, 2025 at 09:58:21PM +0200, Ingo Schwarze wrote:

>> Then again, if the point you want to make is "as a matter of
>> principle, i never test any patch i send", you might want to
>> reconsider because that might discourage people from looking
>> at your patches.  >;co

> This is the approach I recently decided to take, considering what
> happened with my mail(1) patches.

I'm sorry none of those went in so far (unless i missed something).
At least some of them were worthy.  Given more time, i could no
doubt have been more helpful polishing them.

> Suppose I had gone to the trouble of writing a patch that modified the
> behavior I pointed out without regressions, what would have happened?
> That after perhaps weeks of work and testing, I would post the result
> here only to be told that my patch was too large or that the
> modification wasn't acceptable in a simple application like ksh(1).

That's not the recommended way either.

On the one hand, dumping untested, incorrect patches will often not
result in commits, because it forces *others* to do the main work
(when the problem is serious enough, it may succeed anyway, in the
sense of "bad patches triggering good ones").

But playing the lone wolf programmer for weeks, then dumping a giant
patch changing many things at once, is not a good idea either, for
exactly the reason you explain: there is a serious risk that it
turns out at the end the direction wasn't quite right after all.

The trick is to send small patches that implement one specific bugfix
or improvement, that are well-tested and correct already, and that
are easy to understand and verify for others.  That maximizes the
chances of *some* developer taking the time of checking and providing
an OK - and preparing such a good patch rarely takes more than a few
hours.  If it turns out the direction wasn't quite right, not much
was wasted.

Also consider that even sending good patches, success is not
guaranteed.  Consider the 'P' patch i just sent here.  It is small,
foxussed, well-tested, and a detailed rationale was provided.
All the same, i did not get any feedback from developers yet.

Getting patches in is of very different difficulty in different regions
of the tree.  For example, it is exremely easy for manual page patches
because jmc@ is extremely responsive, and other developers also
provide OKs more seasily because the risk of breaking something is quite
small.  Surprisingly, the chance of getting patches into LibreSSL or
OpenSSH is also quite high, even though the code is unusually complicated
and dangerous, because both have close-knit communities of multiple
developers each who are quite responsive.  Getting patches into mail(1)
or ksh(1) is definitely harder because there is not much active
development in them.  The other extreme is pkg_add(1) - i think
during the last twenty years, i tried several times sending a patch
for pkg_add(1) and IIRC, i did not succeed a single time.

To summarize, adopting a worse approach of sending patches
won't help your chances, but further diminish them.

Yours,
  Ingo