Re: "Write a new package" culture instead of patches?

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think it’s just much easier to write helpful.el from scratch
  > than read all the old code and understand it and try to patch
  > it. I could have patched package.el to make it fetch from github
  > repos, but instead I just wrote a quick small package to do that
  > and moved on, which is much easier than reading and understanding
  > package.el and convince people that such change is necessary.

When such patch packages accumulate, they will get in each others' way
because sometimes they will replace the same function with different
patched versions.  To make the unintegrated patches useful together
requires merging them.

Thus, the author of each patch package saves work by not following
through on the job.  Eventually the code in Emacs changes and the
patch package doesn't work any more.

We would like those people to help us merge their code (when it is
useful enough), but We can't tell them what to do.  What can we do?
What should we do?  Here is what I suggest.

* We should not distribute or refer people to patch packages.
If a repo includes more than a tiny fraction of patch packages,
we should consider it low-quality.

* If the job of merging is really easy we could do it straightaway.
Rewriting the change would avoid any need for an assignment.

* When users express interest in a patch package, we should say, "The
right thing to do here is merge that change.  Would you like to do
that work?  Then we could install the patch and support it."


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)