What to do about unmaintained ELPA packages

What to do about unmaintained ELPA packages

[Philip Kaludercic]

Hi,

There are some popular packages on GNU ELPA (and I expect NonGNU ELPA)
that are practically unmaintained.  One example would be Yasnippet that
has been gathering issues and pull requests on GitHub, mostly without
any comments whatsoever.  For example, see
https://github.com/joaotavora/yasnippet/issues.  Does anyone know of any
other packages of this kind?

I'd like to ask, if there some point at which should one should go from
regarding packages like these from "de facto unmaintained" to "actually
abandoned"?  Perhaps if there was no real activity for over a year,
despite constant contributions?  Would it make sense to call for anyone
new to take over maintaining the package?  Or depending on how long the
package has been unmaintained, how popular the package is, how much
effort it would take to apply the changes one could modify the package
in elpa.git/nongnu.git and inform the maintainers that if they decide to
start working on the package again, that there are downstream changes
that they should look at.

Re: What to do about unmaintained ELPA packages

[Stefan Monnier]

Philip Kaludercic [2022-05-29 23:34:14] wrote:
> I'd like to ask, if there some point at which should one should go from
> regarding packages like these from "de facto unmaintained" to "actually
> abandoned"?  Perhaps if there was no real activity for over a year,
> despite constant contributions?  Would it make sense to call for anyone
> new to take over maintaining the package?

Of course, especially for popular packages.

> Or depending on how long the package has been unmaintained, how
> popular the package is, how much effort it would take to apply the
> changes one could modify the package in elpa.git/nongnu.git and inform
> the maintainers that if they decide to start working on the package
> again, that there are downstream changes that they should look at.

Yes, we can use `:url nil` to indicate that `elpa.git` is considered as
"the upstream".  Of course, it's better if the current upstream can be
modified to point back to us as the upstream so as to try avoiding
accidental divergence in the future.


        Stefan

Re: What to do about unmaintained ELPA packages

[Dmitry Gutov]

On 30.05.2022 00:34, Philip Kaludercic wrote:
> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA)
> that are practically unmaintained.  One example would be Yasnippet that
> has been gathering issues and pull requests on GitHub, mostly without
> any comments whatsoever.  For example, see
> https://github.com/joaotavora/yasnippet/issues.  Does anyone know of any
> other packages of this kind?

Talking about yasnippet in particular, it more in the "stable" rather 
than "bitrotten" category, so I wouldn't worry about it too much.

Or definitely not resort to measures like removing the reference to the 
upstream.

> I'd like to ask, if there some point at which should one should go from
> regarding packages like these from "de facto unmaintained" to "actually
> abandoned"?  Perhaps if there was no real activity for over a year,
> despite constant contributions?  Would it make sense to call for anyone
> new to take over maintaining the package?  Or depending on how long the
> package has been unmaintained, how popular the package is, how much
> effort it would take to apply the changes one could modify the package
> in elpa.git/nongnu.git and inform the maintainers that if they decide to
> start working on the package again, that there are downstream changes
> that they should look at.

Personally, carrying over the development on ELPA would seem 
counter-productive. Both due to the reduced potential community of 
contributors and reporters, and because of the wealth of reports, 
discussions and docs that reside at the currently dormant upstream. 
Kinda passive-aggressive, too.

I think the best step right now would be to try to contact Noah and ask 
to share commit access. And if not Noah, then Joao -- he's definitely 
still around.

Re: What to do about unmaintained ELPA packages

[Tim Cross]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 30.05.2022 00:34, Philip Kaludercic wrote:
>> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA)
>> that are practically unmaintained.  One example would be Yasnippet that
>> has been gathering issues and pull requests on GitHub, mostly without
>> any comments whatsoever.  For example, see
>> https://github.com/joaotavora/yasnippet/issues.  Does anyone know of any
>> other packages of this kind?
>
> Talking about yasnippet in particular, it more in the "stable" rather than
> "bitrotten" category, so I wouldn't worry about it too much.
>
> Or definitely not resort to measures like removing the reference to the
> upstream.
>
>> I'd like to ask, if there some point at which should one should go from
>> regarding packages like these from "de facto unmaintained" to "actually
>> abandoned"?  Perhaps if there was no real activity for over a year,
>> despite constant contributions?  Would it make sense to call for anyone
>> new to take over maintaining the package?  Or depending on how long the
>> package has been unmaintained, how popular the package is, how much
>> effort it would take to apply the changes one could modify the package
>> in elpa.git/nongnu.git and inform the maintainers that if they decide to
>> start working on the package again, that there are downstream changes
>> that they should look at.
>
> Personally, carrying over the development on ELPA would seem counter-productive.
> Both due to the reduced potential community of contributors and reporters, and
> because of the wealth of reports, discussions and docs that reside at the
> currently dormant upstream. Kinda passive-aggressive, too.
>
> I think the best step right now would be to try to contact Noah and ask to share
> commit access. And if not Noah, then Joao -- he's definitely still around.


I would agree. First step is to try contacting the repository owner. I
notice in the case of yasnippets, they are active in other projects, so
there may be a good reason none of the issues or PRs are getting action
in that repo. 

I'm not sure there is a 'one size fits all' answer here. We probably
need to look at each case individually. 

I do think both ELPA and non-GNU ELPA would likely benefit from some
statistic showing number of weekly/monthly downloads and/or possibly
some heuristic quality metric i.e. number of open issues, whether the
package has a test suite, number of compiler warnings, days since last
update etc. While none of these are likely sufficient metrics on their
own, perhaps a combination could be useful as an indicator. 

One unfortunate tendency in the current climate is to consider anything
which has not had an update in some time to be abandoned. However, it
could simply be it has reached a stable point of maturity where fewer
updates are necessary or critical enough. 

Re: What to do about unmaintained ELPA packages

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 4128 bytes --]

Tim Cross <theophilusx@gmail.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 30.05.2022 00:34, Philip Kaludercic wrote:
>>> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA)
>>> that are practically unmaintained.  One example would be Yasnippet that
>>> has been gathering issues and pull requests on GitHub, mostly without
>>> any comments whatsoever.  For example, see
>>> https://github.com/joaotavora/yasnippet/issues.  Does anyone know of any
>>> other packages of this kind?
>>
>> Talking about yasnippet in particular, it more in the "stable" rather than
>> "bitrotten" category, so I wouldn't worry about it too much.
>>
>> Or definitely not resort to measures like removing the reference to the
>> upstream.
>>
>>> I'd like to ask, if there some point at which should one should go from
>>> regarding packages like these from "de facto unmaintained" to "actually
>>> abandoned"?  Perhaps if there was no real activity for over a year,
>>> despite constant contributions?  Would it make sense to call for anyone
>>> new to take over maintaining the package?  Or depending on how long the
>>> package has been unmaintained, how popular the package is, how much
>>> effort it would take to apply the changes one could modify the package
>>> in elpa.git/nongnu.git and inform the maintainers that if they decide to
>>> start working on the package again, that there are downstream changes
>>> that they should look at.
>>
>> Personally, carrying over the development on ELPA would seem counter-productive.
>> Both due to the reduced potential community of contributors and reporters, and
>> because of the wealth of reports, discussions and docs that reside at the
>> currently dormant upstream. Kinda passive-aggressive, too.
>>
>> I think the best step right now would be to try to contact Noah and ask to share
>> commit access. And if not Noah, then Joao -- he's definitely still around.
>
>
> I would agree. First step is to try contacting the repository owner. I
> notice in the case of yasnippets, they are active in other projects, so
> there may be a good reason none of the issues or PRs are getting action
> in that repo. 

I agree.  If the maintainer doesn't respond then we can think about
taking any other step.

>
> I'm not sure there is a 'one size fits all' answer here. We probably
> need to look at each case individually. 

That right, because each case differs and has something unique.

>
> I do think both ELPA and non-GNU ELPA would likely benefit from some
> statistic showing number of weekly/monthly downloads and/or possibly
> some heuristic quality metric i.e. number of open issues, whether the
> package has a test suite, number of compiler warnings, days since last
> update etc. While none of these are likely sufficient metrics on their
> own, perhaps a combination could be useful as an indicator. 

Yeah, these will help users to make a better choice.  Although compiler
warnings count and time since last update can be easily calculated, how
can we check a package has a test suite?  And how can we figure out the
number of open issues (or whatever)?  That would need to use many APIs
like GitHub API, GitLab API, Gitea API.  I would also suggest showing
the license of a package (for NonGNU only, as all ELPA packages are
GPL).

By the way, is it OK to use Expat (or MIT) license for elisp packages?

>
> One unfortunate tendency in the current climate is to consider anything
> which has not had an update in some time to be abandoned. However, it
> could simply be it has reached a stable point of maturity where fewer
> updates are necessary or critical enough. 
>

That's exactly me!  I start writing package, and when I have implemented
everything I want, I just put it aside, until I think it needs attention
(either because I or someone else found a bug or because I would like to
add another feature).

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: What to do about unmaintained ELPA packages

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 30.05.2022 00:34, Philip Kaludercic wrote:
>> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA)
>> that are practically unmaintained.  One example would be Yasnippet that
>> has been gathering issues and pull requests on GitHub, mostly without
>> any comments whatsoever.  For example, see
>> https://github.com/joaotavora/yasnippet/issues.  Does anyone know of any
>> other packages of this kind?
>
> Talking about yasnippet in particular, it more in the "stable" rather
> than "bitrotten" category, so I wouldn't worry about it too much.
>
> Or definitely not resort to measures like removing the reference to
> the upstream.

Considering the number of issues that have been gathering in the above
mentioned issue tracker, I find it increasingly difficult to say it is
"stable".  It is far from being "bitrotten", but there is plenty of
space between the two.

>> I'd like to ask, if there some point at which should one should go from
>> regarding packages like these from "de facto unmaintained" to "actually
>> abandoned"?  Perhaps if there was no real activity for over a year,
>> despite constant contributions?  Would it make sense to call for anyone
>> new to take over maintaining the package?  Or depending on how long the
>> package has been unmaintained, how popular the package is, how much
>> effort it would take to apply the changes one could modify the package
>> in elpa.git/nongnu.git and inform the maintainers that if they decide to
>> start working on the package again, that there are downstream changes
>> that they should look at.
>
> Personally, carrying over the development on ELPA would seem
> counter-productive. Both due to the reduced potential community of
> contributors and reporters, and because of the wealth of reports,
> discussions and docs that reside at the currently dormant
> upstream. Kinda passive-aggressive, too.

That would only be one option, perhaps the most drastic because it
burdens the ELPA maintainers and contributors the most.  An alternative
would be to announce a package is regarded as unmaintained and that we
are looking for a new maintainer to revive the package by start a fork.

My intention with this thread is to formalise some kind of workflow for
situations like these, so that people know what they can do if a ELPA
package stagnates.

> I think the best step right now would be to try to contact Noah and
> ask to share commit access. And if not Noah, then Joao -- he's
> definitely still around.

I have CC'ed them in this message, in case they have anything to say on
this specific case.

Re: What to do about unmaintained ELPA packages

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> Considering the number of issues that have been gathering in the above
> mentioned issue tracker, I find it increasingly difficult to say it is
> "stable".

Seems like a bit more than 10% of issues opened are still open?  That's
not a bad track record -- it's about where we are in the Emacs bug
tracker.  😰

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: What to do about unmaintained ELPA packages

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]

On Mon, May 30, 2022 at 7:58 AM Philip Kaludercic <philipk@posteo.net>
wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> Considering the number of issues that have been gathering in the above
> mentioned issue tracker, I find it increasingly difficult to say it is
> "stable".  It is far from being "bitrotten", but there is plenty of
> space between the two.


Yes, I agree with this characterization.  Yasnippet's "display engine",
though
highly tested (automatically and manually) is complex.  I recall some bugs
when interacting with other packages that make heavy use of indenting tricks
and overlays.  While these are the minority (as far as I know), Org is one
such package and it's pretty prominent.

On the other hand, last time browsed the issue tracker, there were very
many
specialized feature requests that wouldn't (IMO) make sense in the Yasnippet
engine.  Integrating them would be hard and awkward and it would turn it
into
something else entirely. So, in that sense, Yasnippet is stable.

One interesting area of Yasnippet development is in its 'snippet-engine'
branch, in a file called simply snippet.e'.  It is the product of an
exchange of
ideas between me and Stefan Monnier some years ago.  It's a bare-bones
version
of Yasnippet's snippet expansion and navigation engine, more efficient and
Lisp-friendly.  The goal was to replace Yasnippet's engine in the master
branch
with it.

Alas, motivation fizzled and work stalled.  But it was pretty spiffy and
almost
done.  As I recall, snippet definitions were simply Elisp forms, written in
a
nice DSL which was not particularly obtrusive.  snippet.el is more or less
yasnippet.el done right.

snippet.el could be useful in light of a relatively recent development:
LSP.

If I've ever actually used Yasnippet recently, it's been through LSP/eglot,
completely transparently.  When used though LSP, a lot of Yasnippet's
legacy,
bug-prone, wish-I-was-Textmate, dont-really-know-elisp code isn't being
exercised at all.

I've personally abandoned the idea of maintaining personal or shared
language-specific snippet collections via many little text files.  I would
guess
others have, too.  LSP servers simply maintain that collection for you, as
they do so many other things, and that's agreeable to me.

It's true that LSP still uses the Textmate snippet description language, and
snippet.el accepts Lisp forms (as it should).  But translating from the
former
to the latter isn't very hard (in fact someone over at the repo did it some
years
ago).

To summarize, I don't have any particularly strong opinion on what should
be done
with Yasnippet. In fact, I don't even know what problem Philip is trying to
solve!
Is it just the general idea of abandonment of the fact that people's issue
reports
go unanswered?  If the latter, then I think archiving the repo would make
sense.  No
more issue reports would come in and one could advertise the Emacs bug
tracker.
Would that improve things?

I do think that it's important to preserve the documentation though, as
many people
seem to refer to it still. Or maybe transfer it to a more GNU ELPAish
location/format.

Who knows if the description above motivates someone to pick up
'snippet.el',
finalize it, and make a new GNU ELPA package?  Or maybe it motivates someone
to pick up the maintenance of the existing Yasnippet.

So let me and Noam know if you wish me to do something admin with the
repository.
While Noam is the official maintainer, I think I still retain those rights.

João

[-- Attachment #2: Type: text/html, Size: 4820 bytes --]

Re: What to do about unmaintained ELPA packages

[Ergus]

On Mon, May 30, 2022 at 03:46:11PM +0100, Jo�o T�vora wrote:
>On Mon, May 30, 2022 at 7:58 AM Philip Kaludercic <philipk@posteo.net>
>wrote:
>
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>> Considering the number of issues that have been gathering in the above
>> mentioned issue tracker, I find it increasingly difficult to say it is
>> "stable".  It is far from being "bitrotten", but there is plenty of
>> space between the two.
>
>
>Yes, I agree with this characterization.  Yasnippet's "display engine",
>though
>highly tested (automatically and manually) is complex.  I recall some bugs
>when interacting with other packages that make heavy use of indenting tricks
>and overlays.  While these are the minority (as far as I know), Org is one
>such package and it's pretty prominent.
>
>On the other hand, last time browsed the issue tracker, there were very
>many
>specialized feature requests that wouldn't (IMO) make sense in the Yasnippet
>engine.  Integrating them would be hard and awkward and it would turn it
>into
>something else entirely. So, in that sense, Yasnippet is stable.
>
>One interesting area of Yasnippet development is in its 'snippet-engine'
>branch, in a file called simply snippet.e'.  It is the product of an
>exchange of
>ideas between me and Stefan Monnier some years ago.  It's a bare-bones
>version
>of Yasnippet's snippet expansion and navigation engine, more efficient and
>Lisp-friendly.  The goal was to replace Yasnippet's engine in the master
>branch
>with it.
>
>Alas, motivation fizzled and work stalled.  But it was pretty spiffy and
>almost
>done.  As I recall, snippet definitions were simply Elisp forms, written in
>a
>nice DSL which was not particularly obtrusive.  snippet.el is more or less
>yasnippet.el done right.
>
>snippet.el could be useful in light of a relatively recent development:
>LSP.
>
>If I've ever actually used Yasnippet recently, it's been through LSP/eglot,
>completely transparently.  When used though LSP, a lot of Yasnippet's
>legacy,
>bug-prone, wish-I-was-Textmate, dont-really-know-elisp code isn't being
>exercised at all.
>
>I've personally abandoned the idea of maintaining personal or shared
>language-specific snippet collections via many little text files.  I would
>guess
>others have, too.  LSP servers simply maintain that collection for you, as
>they do so many other things, and that's agreeable to me.
>
>It's true that LSP still uses the Textmate snippet description language, and
>snippet.el accepts Lisp forms (as it should).  But translating from the
>former
>to the latter isn't very hard (in fact someone over at the repo did it some
>years
>ago).
>
>To summarize, I don't have any particularly strong opinion on what should
>be done
>with Yasnippet. In fact, I don't even know what problem Philip is trying to
>solve!
>Is it just the general idea of abandonment of the fact that people's issue
>reports
>go unanswered?  If the latter, then I think archiving the repo would make
>sense.  No
>more issue reports would come in and one could advertise the Emacs bug
>tracker.
>Would that improve things?
>
>I do think that it's important to preserve the documentation though, as
>many people
>seem to refer to it still. Or maybe transfer it to a more GNU ELPAish
>location/format.
>
>Who knows if the description above motivates someone to pick up
>'snippet.el',
>finalize it, and make a new GNU ELPA package?  Or maybe it motivates someone
>to pick up the maintenance of the existing Yasnippet.
>
>So let me and Noam know if you wish me to do something admin with the
>repository.
>While Noam is the official maintainer, I think I still retain those rights.
>
>Jo�o


Hi Joao:

So far depending too much on lsp has some issues I am not sure they are
all already solved in order to make yasnippet substitute its backends:

1) LSP+Tramp works pretty bad; specially with relatively big/medium
projects it becaumes extremely slow and gives the error message of
reentrant calls... also it depends on having LSP on the remote host.

2) It is difficult to use LSP for quick tests.. suppose it wants to test
a simple program... usually I open /tmp/main.c and start writing... with
LSP Eglot it needs to know how to compile it to give completions like
inserting main(int argc...). flymake depends on a Makefile, LSP of a
database...

3) Bear is also problematic as it now adds a lost of extra dependencies,
so projects with autotools has a problem to create the build
database...

4) When build is out of source (something that is becoming more common
in autotools and cmake also prefers) the build and database creation and
update requires constant extra effort, something most of the IDE do for
the user.

5) Do you have documented how to make eglot integration with yasnippet?
Because I can't make it work.

If you have ways to go around these issues I will be very grated if you
share them, so I could try eglot+yasnippet for daily use.

Thanks in advance Ergus.

Re: What to do about unmaintained ELPA packages

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 6644 bytes --]

Ergus,

I think you're veering a little bit from the issue here, but the goal is not
to throw anything away: I was just expounding my vision of a new
snippet system with less code, less bugs, and less friction that is driven
by LSP servers as more reliable owners and maintainers of snippet
collections.

For 2. I open one-shot ~/tmp/test.cpp files and type M-x eglot and get
decent
results all the time.  Also bear works nicely for me.  But mostly the C++
projects I've been doing lately use Cmake which creates a
compile-commands.json file anyway.

For number 5, just have yasnippet installed, simple as that: Eglo should
pick it up by default.  Any other problems, please start a conversation in
Eglot's "discussions" panel, or, if you have complete information on how to
recreate a given situation problem, create an issue.

Anyway, it sounds like you are describing LSP/Eglot shortcomings.  Sure,
there
are a lot of them, but trying to stop it is like trying to stop the tide,
at least
I feel it is.  And it's been working fine for me (actually I've only very
recently
actually started using it, after having created maintained Eglot for it for
4+
years).

João

On Mon, May 30, 2022 at 11:51 PM Ergus <spacibba@aol.com> wrote:

> On Mon, May 30, 2022 at 03:46:11PM +0100, Jo�o T�vora wrote:
> >On Mon, May 30, 2022 at 7:58 AM Philip Kaludercic <philipk@posteo.net>
> >wrote:
> >
> >> Dmitry Gutov <dgutov@yandex.ru> writes:
> >>
> >> Considering the number of issues that have been gathering in the above
> >> mentioned issue tracker, I find it increasingly difficult to say it is
> >> "stable".  It is far from being "bitrotten", but there is plenty of
> >> space between the two.
> >
> >
> >Yes, I agree with this characterization.  Yasnippet's "display engine",
> >though
> >highly tested (automatically and manually) is complex.  I recall some bugs
> >when interacting with other packages that make heavy use of indenting
> tricks
> >and overlays.  While these are the minority (as far as I know), Org is one
> >such package and it's pretty prominent.
> >
> >On the other hand, last time browsed the issue tracker, there were very
> >many
> >specialized feature requests that wouldn't (IMO) make sense in the
> Yasnippet
> >engine.  Integrating them would be hard and awkward and it would turn it
> >into
> >something else entirely. So, in that sense, Yasnippet is stable.
> >
> >One interesting area of Yasnippet development is in its 'snippet-engine'
> >branch, in a file called simply snippet.e'.  It is the product of an
> >exchange of
> >ideas between me and Stefan Monnier some years ago.  It's a bare-bones
> >version
> >of Yasnippet's snippet expansion and navigation engine, more efficient and
> >Lisp-friendly.  The goal was to replace Yasnippet's engine in the master
> >branch
> >with it.
> >
> >Alas, motivation fizzled and work stalled.  But it was pretty spiffy and
> >almost
> >done.  As I recall, snippet definitions were simply Elisp forms, written
> in
> >a
> >nice DSL which was not particularly obtrusive.  snippet.el is more or less
> >yasnippet.el done right.
> >
> >snippet.el could be useful in light of a relatively recent development:
> >LSP.
> >
> >If I've ever actually used Yasnippet recently, it's been through
> LSP/eglot,
> >completely transparently.  When used though LSP, a lot of Yasnippet's
> >legacy,
> >bug-prone, wish-I-was-Textmate, dont-really-know-elisp code isn't being
> >exercised at all.
> >
> >I've personally abandoned the idea of maintaining personal or shared
> >language-specific snippet collections via many little text files.  I would
> >guess
> >others have, too.  LSP servers simply maintain that collection for you, as
> >they do so many other things, and that's agreeable to me.
> >
> >It's true that LSP still uses the Textmate snippet description language,
> and
> >snippet.el accepts Lisp forms (as it should).  But translating from the
> >former
> >to the latter isn't very hard (in fact someone over at the repo did it
> some
> >years
> >ago).
> >
> >To summarize, I don't have any particularly strong opinion on what should
> >be done
> >with Yasnippet. In fact, I don't even know what problem Philip is trying
> to
> >solve!
> >Is it just the general idea of abandonment of the fact that people's issue
> >reports
> >go unanswered?  If the latter, then I think archiving the repo would make
> >sense.  No
> >more issue reports would come in and one could advertise the Emacs bug
> >tracker.
> >Would that improve things?
> >
> >I do think that it's important to preserve the documentation though, as
> >many people
> >seem to refer to it still. Or maybe transfer it to a more GNU ELPAish
> >location/format.
> >
> >Who knows if the description above motivates someone to pick up
> >'snippet.el',
> >finalize it, and make a new GNU ELPA package?  Or maybe it motivates
> someone
> >to pick up the maintenance of the existing Yasnippet.
> >
> >So let me and Noam know if you wish me to do something admin with the
> >repository.
> >While Noam is the official maintainer, I think I still retain those
> rights.
> >
> >Jo�o
>
>
> Hi Joao:
>
> So far depending too much on lsp has some issues I am not sure they are
> all already solved in order to make yasnippet substitute its backends:
>
> 1) LSP+Tramp works pretty bad; specially with relatively big/medium
> projects it becaumes extremely slow and gives the error message of
> reentrant calls... also it depends on having LSP on the remote host.
>
> 2) It is difficult to use LSP for quick tests.. suppose it wants to test
> a simple program... usually I open /tmp/main.c and start writing... with
> LSP Eglot it needs to know how to compile it to give completions like
> inserting main(int argc...). flymake depends on a Makefile, LSP of a
> database...
>
> 3) Bear is also problematic as it now adds a lost of extra dependencies,
> so projects with autotools has a problem to create the build
> database...
>
> 4) When build is out of source (something that is becoming more common
> in autotools and cmake also prefers) the build and database creation and
> update requires constant extra effort, something most of the IDE do for
> the user.
>
> 5) Do you have documented how to make eglot integration with yasnippet?
> Because I can't make it work.
>
> If you have ways to go around these issues I will be very grated if you
> share them, so I could try eglot+yasnippet for daily use.
>
> Thanks in advance Ergus.
>


-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 8093 bytes --]

Re: What to do about unmaintained ELPA packages

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> To summarize, I don't have any particularly strong opinion on what should
> be done
> with Yasnippet. In fact, I don't even know what problem Philip is trying to
> solve!

To be specific, my issue was mentioned here:
https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid
false-positives when expanding snippets").  In my case, I have managed
to circumvent the issue by unbinding the tab key and relying in
hippie-expand, but the solution is not elegant and I would have
appreciated a discussion on the issue tracker.

The point was not to say that yasnippet has been abandoned, just to give
an example where the liveliness of development could be questioned.

> Is it just the general idea of abandonment of the fact that people's
> issue reports go unanswered?  If the latter, then I think archiving
> the repo would make sense.  No more issue reports would come in and
> one could advertise the Emacs bug tracker.  Would that improve things?

I guess, but I think it would be preferable to call for someone to fork
the package instead of shifting the burden of maintenance onto the emacs
bug tracker.

> I do think that it's important to preserve the documentation though, as
> many people
> seem to refer to it still. Or maybe transfer it to a more GNU ELPAish
> location/format.
>
> Who knows if the description above motivates someone to pick up
> 'snippet.el', finalize it, and make a new GNU ELPA package?  Or maybe
> it motivates someone to pick up the maintenance of the existing
> Yasnippet.

Due to a sudden increase in free time available to me, I might consider
this.

Re: What to do about unmaintained ELPA packages

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 3586 bytes --]

On Tue, May 31, 2022, 17:42 Philip Kaludercic <philipk@posteo.net> wrote:

To be specific, my issue was mentioned here:
> https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid
> false-positives when expanding snippets").  In my case, I have managed
> to circumvent the issue by unbinding the tab key and relying in
> hippie-expand, but the solution is not elegant and I would have
> appreciated a discussion on the issue tracker.
>

Does it really matter where the discussion happens? The problem
here is not the place, it's the unavailability of brain-hours to dedicate
to your request.

The point was not to say that yasnippet has been abandoned, just to give
> an example where the liveliness of development could be questioned.
>

You don't have to sugar-coat it. Yasnippet's bug reports have gone
unanswered
at least for a year. They don't make it into my inbox, I'm not the
maintainer
anymore. Noam did a thorough and excellent job while he was maintaining it,
he's not available anymore. It's de facto unmaintained, though rather
stable
in its intended use case.  Of course Emacs is gigantic and everyone wants
everything, and so it might not be doing what you want.  I understand that.

In that sense, it'd be nice if yasnippet wasn't' the monolithic package it
is,
and 'snippet.el' is a step in that direction.  Then you could perhaps opt
out
(or in) to the multi-file, keybinding, abbrev-like functionality of
yasnippet.el.
Or simply compose 'snippet.el' bare-bones expansion/navigation with
whatever other productivity tool where you think  snippets make sense.
Eglot is one of those tools and it works well with yasnippet today.  I'd
love to
make it depend on simply 'snippet.el'.

> Is it just the general idea of abandonment of the fact that people's
> > issue reports go unanswered?  If the latter, then I think archiving to
> > the repo would make sense.  No more issue reports would come in and
> > one could advertise the Emacs bug tracker.  Would that improve things?
>
> I guess, but I think it would be preferable to call for someone to fork
> the package instead of shifting the burden of maintenance onto the emacs
> bug tracker.
>

Again, i don't quite understand how that magically solves the root problem
You're free to fork when you want, of course, but that normally happens
when you want to take the software in a new irreconcilable new direction.
Currently, yasnippet just needs (1) a maintainer that understands the
current functionality and "protects" it, fixing bugs, not introducing new
ones.
New features are probably not a great idea. (2) someone to develop
'snippet.el'
into production-ready state and make 'yasnippet.el' depend on it, then may
integrate make 'snippet.el' into a new package. The person of (1) and (2)
can
be the same.

> it motivates someone to pick up the maintenance of the existing
> > Yasnippet.
>
> Due to a sudden increase in free time available to me, I might consider
> this.
>

Great, if you're serious about it drop me a line stating more or less what
your plan is. I don't know if you've read the code: it's not exactly a work
of art (at least my parts aren't) :-) If you'd prefer a more palatable
challenge,
you could opt to simply develop the somewhat nicer 'snippet.el'.  It'd be
fine
to create your own repo to host and develop it (say in that shiny SourceHut
account where we discussed a bug the other day).

João

PS: in the meantime, it seems that Dmitry suggested what seems like a
reasonable way to address your request.

[-- Attachment #2: Type: text/html, Size: 5729 bytes --]

Re: What to do about unmaintained ELPA packages

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 4623 bytes --]

Here are my 2 cents of the topic in general - unmaintained packages are not an Emacs-specific issue and they exist in every programming community. I don't really think we need some special policy on handling them, as:

- if a package is really valuable new maintainers will always be found
- if something is in a really bad state people will just stop using it

Spending our limited efforts on policing the ELPA packages and trying to decide if something is "properly maintained" is not going to amount to much IMO. If someone uses a package and thinks it's valuable then it probably is. A package doesn't need to be perfect to be useful.

It feels to me there's no real problem to be solved here. If we want to discuss what to do about specific packages (e.g. yasnippet) to improve their state - that's a completely different topic. 

On Wed, Jun 1, 2022, at 1:08 AM, João Távora wrote:
> On Tue, May 31, 2022, 17:42 Philip Kaludercic <philipk@posteo.net> wrote:
> 
>> To be specific, my issue was mentioned here:
>> https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid
>> false-positives when expanding snippets").  In my case, I have managed
>> to circumvent the issue by unbinding the tab key and relying in
>> hippie-expand, but the solution is not elegant and I would have
>> appreciated a discussion on the issue tracker.
> 
> Does it really matter where the discussion happens? The problem 
> here is not the place, it's the unavailability of brain-hours to dedicate 
> to your request.
> 
>> The point was not to say that yasnippet has been abandoned, just to give
>> an example where the liveliness of development could be questioned.
> 
> You don't have to sugar-coat it. Yasnippet's bug reports have gone unanswered 
> at least for a year. They don't make it into my inbox, I'm not the maintainer
> anymore. Noam did a thorough and excellent job while he was maintaining it, 
> he's not available anymore. It's de facto unmaintained, though rather stable 
> in its intended use case.  Of course Emacs is gigantic and everyone wants 
> everything, and so it might not be doing what you want.  I understand that.
> 
> 
> In that sense, it'd be nice if yasnippet wasn't' the monolithic package it is, 
> and 'snippet.el' is a step in that direction.  Then you could perhaps opt out 
> (or in) to the multi-file, keybinding, abbrev-like functionality of yasnippet.el.  
> Or simply compose 'snippet.el' bare-bones expansion/navigation with 
> whatever other productivity tool where you think  snippets make sense. 
> Eglot is one of those tools and it works well with yasnippet today.  I'd love to
> make it depend on simply 'snippet.el'.
> 
>> > Is it just the general idea of abandonment of the fact that people's
>> > issue reports go unanswered?  If the latter, then I think archiving to
>> > the repo would make sense.  No more issue reports would come in and
>> > one could advertise the Emacs bug tracker.  Would that improve things?
>> 
>> I guess, but I think it would be preferable to call for someone to fork
>> the package instead of shifting the burden of maintenance onto the emacs
>> bug tracker.
> 
> Again, i don't quite understand how that magically solves the root problem
> You're free to fork when you want, of course, but that normally happens 
> when you want to take the software in a new irreconcilable new direction.
> 
> Currently, yasnippet just needs (1) a maintainer that understands the 
> current functionality and "protects" it, fixing bugs, not introducing new ones.
> New features are probably not a great idea. (2) someone to develop 'snippet.el' 
> into production-ready state and make 'yasnippet.el' depend on it, then may 
> integrate make 'snippet.el' into a new package. The person of (1) and (2) can 
> be the same.
> 
>> > it motivates someone to pick up the maintenance of the existing
>> > Yasnippet.
>> 
>> Due to a sudden increase in free time available to me, I might consider
>> this.
> 
> Great, if you're serious about it drop me a line stating more or less what
> your plan is. I don't know if you've read the code: it's not exactly a work 
> of art (at least my parts aren't) :-) If you'd prefer a more palatable challenge, 
> you could opt to simply develop the somewhat nicer 'snippet.el'.  It'd be fine 
> to create your own repo to host and develop it (say in that shiny SourceHut
> account where we discussed a bug the other day). 
> 
> João
> 
> PS: in the meantime, it seems that Dmitry suggested what seems like a 
> reasonable way to address your request.
> 
> 

[-- Attachment #2: Type: text/html, Size: 7563 bytes --]

Re: What to do about unmaintained ELPA packages

[Richard Stallman]

[[[ 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. ]]]

Ummaintained packages can occur in any collection of packages.  This
may not be a disaster.  But if the overall project wants to do a good
job, it should try to arrange to get them maintained again.

Our choices about how to organize this can get us better results or
worse results.  Let's make a small effort to get the better results.

If you define "real problem" as disaster, well, I agree there isn't a
disaster.  But there is an opportunity.  Let's take it.

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

Re: What to do about unmaintained ELPA packages

[Richard Stallman]

[[[ 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'd like to ask, if there some point at which should one should go from
  > regarding packages like these from "de facto unmaintained" to "actually
  > abandoned"?  Perhaps if there was no real activity for over a year,
  > despite constant contributions?  Would it make sense to call for anyone
  > new to take over maintaining the package?

There is no need to have a rigid rule about this, but we should have a
rough guide to go by.  "Serious problems go unfixed for a year" sounds
like enough reason to judge that there is a problem in maintaining
that package.  We don't need a rule about what we do if that happens,
but we should take note of such packages and decide what to do.

If a package is important enough, we might want to take action sooner
than that.  We can fix any GNU ELPA package if we see fit.  We should
try to discuss that with its maintainers first, but if they are
nonresponsive, we don't have to wait to satisfy some rule.

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

Re: What to do about unmaintained ELPA packages

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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'd like to ask, if there some point at which should one should go from
>   > regarding packages like these from "de facto unmaintained" to "actually
>   > abandoned"?  Perhaps if there was no real activity for over a year,
>   > despite constant contributions?  Would it make sense to call for anyone
>   > new to take over maintaining the package?
>
> There is no need to have a rigid rule about this, but we should have a
> rough guide to go by.  "Serious problems go unfixed for a year" sounds
> like enough reason to judge that there is a problem in maintaining
> that package.  We don't need a rule about what we do if that happens,
> but we should take note of such packages and decide what to do.

"Serious problems go unfixed for a year" - I don't think this is always
a result of maintainance problem.  It may happen that the maintainer is
unable to fix it, because either they aren't smart enough or they can't
fix it due any other problem (maybe upstream bug, or they don't own the
machine needed to reproduce and fix the problem).

>
> If a package is important enough, we might want to take action sooner
> than that.  We can fix any GNU ELPA package if we see fit.  We should
> try to discuss that with its maintainers first, but if they are
> nonresponsive, we don't have to wait to satisfy some rule.

Yeah, we can fix GNU ELPA packages, since those are part of Emacs.

But what about NonGNU ELPA packages?  I think we should try to talk with
the maintainer, and possibly send a fix if its appropiate to do so.  And
in case they aren't responding, we should add a notice like UNMAINTAINED
in the summany line.  We can also to remove the package, but I think its
not right to do so, for the user's sake.

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

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: What to do about unmaintained ELPA packages

[Stefan Monnier]

> Yeah, we can fix GNU ELPA packages, since those are part of Emacs.
> But what about NonGNU ELPA packages?

Actually, for the majority of packages, there is virtually no difference
between GNU and NonGNU in this respect: their official development takes
place elsewhere but we have our own branch in elpa.git/nongnu.git where
we can install any changes we may want.

And in both cases, installing changes on our own branch means that the
development has diverged ("forked"), which will spell pain in the future
if/when upstream's development continues.

IOW: we can do it, but there are strong motivations to refrain from
doing it.


        Stefan

Re: What to do about unmaintained ELPA packages

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yeah, we can fix GNU ELPA packages, since those are part of Emacs.
>> But what about NonGNU ELPA packages?
>
> Actually, for the majority of packages, there is virtually no difference
> between GNU and NonGNU in this respect: their official development takes
> place elsewhere but we have our own branch in elpa.git/nongnu.git where
> we can install any changes we may want.
>
> And in both cases, installing changes on our own branch means that the
> development has diverged ("forked"), which will spell pain in the future
> if/when upstream's development continues.
>
> IOW: we can do it, but there are strong motivations to refrain from
> doing it.
>
>
>         Stefan
>

Then we can, as I suggested in a previous message, add UNMAINTAINED to
the summary line of the package.  Thus users will know that its no
longer maintained.  And as soon as we get an update, we can remove it.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]