Re: Magit-inspired Emacs interface for Sapling (sl)

swithin chan <[email protected]> writes:

> Dear all,Sorry for the bothering of LLM problems. I just tested some
> functions of sapling in windows, Meta’s sapling in Microsoft Windows
> is broken anyway. The sapling version control happens to be better in
> Linux than windows(sapling.el works better in Linux too). It happens I
> donated a package that works better in Linux!  I just want to offload
> this package for now if this LLM argument continues. 

This is actually concerning, one of our soft constraints for ELPA is
"Are you interested in maintaining the package long term?", and I don't
think it is reasonable to expect others to maintain a package that they
don't have a use for or familiarity with.  This is especially an issue
with packages that interface with external tools that can change and
have to follow upstream development.

This is an issue of LLM generated packages, that the likelihood of
someone loosing interest in it is much higher than with a hand-written
package where the act of writing it is at least some kind of a "proof of
interest" in the package.

I am not sure if the right course of action is to remove the package for
now, or if you could amend the documentation to make it clear that the
package is not maintained and that you'd be willing to donate to the
package to someone willing to take over.

In the spirit of curating ELPA and improving the experience of using
Emacs, I'd argue we don't want to have broken packages in the archive.

(Another suggestion that has been brought up elsewhere is to have a
restriction on LLM generated packages submitted to NonGNU ELPA, that
they have to be older than a month or I guess some other indicator that
the package will probably not be forgotten.)

>                                                      I will stick to
> using git + gitk command line in windows first.  yasnippet is good for
> boilerplate codes btw especially powershell scripting. I have revised
> many sapling-menu options for the sapling.el package, i will leave it
> for now.
>
> Sent from Yahoo Mail for iPhone
>
>
> On Friday, August 28, 2026, 12:33 AM, Richard Stallman <[email protected]> wrote:
>
> [[[ 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. ]]]
>
>   > We use the "Assisted-by" header because it appears that this header
>   > is commonly used by all kinds of unrelated projects, communities and
>   > companies.  It has the advantage that it does not make a value judgment.
>   > Those who want to avoid LLM-generated software can treat it as a "do not
>   > use" boolean,
>
> This seems to equate "assisted by LLM foo" with "some of this code was
> generated by LLM foo".  That is incorrect in general, because there
> are other ways to get assistance from an LLM without its generating
> code.
>
> So if in the future we want a tag to indicate that some code was
> generated by an LLM, it should not be "assisted by".
>
> At present, we have a policy of rejecting LLM-generated code in GNU
> programs.  That should include GNU ELPA and NonGNU ELPA -- because
> both parts of ELPA are associated with GNU Emacs, and leads people to
> load packages from both parts of ELPA.