From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bozhidar Batsov" Newsgroups: gmane.emacs.devel Subject: Re: What to do about unmaintained ELPA packages Date: Wed, 01 Jun 2022 08:57:30 +0300 Message-ID: References: <87k0a42fc9.fsf@posteo.net> <8a6d74f7-b78f-3dad-1bd5-f41354f4391f@yandex.ru> <871qwb5wxv.fsf@posteo.net> <87bkvd4ps5.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=fb85c3a9fadc4ca6bd53215d56744b3d Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1027"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 To: "Emacs Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 01 08:01:32 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwHQ9-000AVE-5n for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Jun 2022 08:01:31 +0200 Original-Received: from localhost ([::1]:44026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nwHQ7-0004qo-Ps for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Jun 2022 02:01:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwHMm-0002v9-C7 for emacs-devel@gnu.org; Wed, 01 Jun 2022 01:58:00 -0400 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:58723) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwHMj-00024B-Fe for emacs-devel@gnu.org; Wed, 01 Jun 2022 01:58:00 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 279A83200AFB for ; Wed, 1 Jun 2022 01:57:52 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 01 Jun 2022 01:57:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1654063071; x=1654149471; bh=SXFjHd6siH GQv8wNDs5jmGqgiPo0595gNhIZKOmQ2yA=; b=OBHawJxeSPAUqDgKY+4Ax4kU3H UpITkUvEBuM8LEkDZmjl/bqPatjuLScziuQA71C2wyq6wUIv5sUBOHdKVirmjTWz XJsgOw8pGh18EqBkhPJ9GQ25FqaGtbgDDXF7QX420/lYXNxrld0r6J6uhUofu1qi vCU43s/vtTekMu2f/gqNT4iCKNAPcq4/FNSKe/cd4QnCRLOyQIvZ4l83thg3EyG6 rQr3Jh3GK91FEsZiq85Tch7NdHLkzn+aa59uL5BvP5hCYMnEIsQaEQ8qnOaP3JXk 7I0TwtFq9D5cPX3xAQjrEsd9ZSJyNCSbCtEhD8tJuUH2zeAYIc9RIicqo8IQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1654063071; x=1654149471; bh=SXFjHd6siHGQv8wNDs5jmGqgiPo0 595gNhIZKOmQ2yA=; b=cZ5keQiB1f33RxuFuZBMfQvXm7VPw7PW006H/mOMG4WY 6HnMWF8Pi3QMxfU8Ipc626DokkPf+cWkIOpGp+hNsJrQXQgFqpBt+kjve8lFJ9C9 lTnSSAOF6wT20ARSJaQZmBm92pBSL6FRk0XDRJjRzCJ70C8vJQx0UtlCkYAtI+M8 +ATjmO0swRCL7QP5OZMrwI6x3UN3wRA+TzCPKN1b6R2K5KU3xyNJb/GAdG8G7Jc3 g/dJrZstC3yB0cWwwcDTI60uLaX0gCjRE0Wu4TzicwDqrITUHteCotqeKKIRwb/K aZnlL60ArRBDt8ESNeaVeAmDuH6E29OqPNKj+XJy2A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrkeelgdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehoiihh ihgurghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvheqne cuggftrfgrthhtvghrnhepgeegkeefgffgtdelkeeltdejvedtkedvtdevffefgeetteef hefhgfdufefhheegnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpvghlrdhithdpvg hlrdhishenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegsohiihhhiuggrrhessggrthhsohhvrdguvghv X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 638E42D4006D; Wed, 1 Jun 2022 01:57:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: Received-SPF: pass client-ip=64.147.123.24; envelope-from=bozhidar@batsov.dev; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:290469 Archived-At: --fb85c3a9fadc4ca6bd53215d56744b3d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are my 2 cents of the topic in general - unmaintained packages are = not an Emacs-specific issue and they exist in every programming communit= y. 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 pro= bably 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 t= heir state - that's a completely different topic.=20 On Wed, Jun 1, 2022, at 1:08 AM, Jo=C3=A3o T=C3=A1vora wrote: > On Tue, May 31, 2022, 17:42 Philip Kaludercic wro= te: >=20 >> 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. >=20 > Does it really matter where the discussion happens? The problem=20 > here is not the place, it's the unavailability of brain-hours to dedic= ate=20 > to your request. >=20 >> The point was not to say that yasnippet has been abandoned, just to g= ive >> an example where the liveliness of development could be questioned. >=20 > You don't have to sugar-coat it. Yasnippet's bug reports have gone una= nswered=20 > at least for a year. They don't make it into my inbox, I'm not the mai= ntainer > anymore. Noam did a thorough and excellent job while he was maintainin= g it,=20 > he's not available anymore. It's de facto unmaintained, though rather = stable=20 > in its intended use case. Of course Emacs is gigantic and everyone wa= nts=20 > everything, and so it might not be doing what you want. I understand = that. >=20 >=20 > In that sense, it'd be nice if yasnippet wasn't' the monolithic packag= e it is,=20 > and 'snippet.el' is a step in that direction. Then you could perhaps = opt out=20 > (or in) to the multi-file, keybinding, abbrev-like functionality of ya= snippet.el. =20 > Or simply compose 'snippet.el' bare-bones expansion/navigation with=20 > whatever other productivity tool where you think snippets make sense.=20 > Eglot is one of those tools and it works well with yasnippet today. I= 'd love to > make it depend on simply 'snippet.el'. >=20 >> > 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 thin= gs? >>=20 >> I guess, but I think it would be preferable to call for someone to fo= rk >> the package instead of shifting the burden of maintenance onto the em= acs >> bug tracker. >=20 > Again, i don't quite understand how that magically solves the root pro= blem > You're free to fork when you want, of course, but that normally happen= s=20 > when you want to take the software in a new irreconcilable new directi= on. >=20 > Currently, yasnippet just needs (1) a maintainer that understands the=20 > current functionality and "protects" it, fixing bugs, not introducing = new ones. > New features are probably not a great idea. (2) someone to develop 'sn= ippet.el'=20 > into production-ready state and make 'yasnippet.el' depend on it, then= may=20 > integrate make 'snippet.el' into a new package. The person of (1) and = (2) can=20 > be the same. >=20 >> > it motivates someone to pick up the maintenance of the existing >> > Yasnippet. >>=20 >> Due to a sudden increase in free time available to me, I might consid= er >> this. >=20 > 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=20 > of art (at least my parts aren't) :-) If you'd prefer a more palatable= challenge,=20 > you could opt to simply develop the somewhat nicer 'snippet.el'. It'd= be fine=20 > to create your own repo to host and develop it (say in that shiny Sour= ceHut > account where we discussed a bug the other day).=20 >=20 > Jo=C3=A3o >=20 > PS: in the meantime, it seems that Dmitry suggested what seems like a=20 > reasonable way to address your request. >=20 >=20 --fb85c3a9fadc4ca6bd53215d56744b3d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Here are my 2 c= ents of the topic in general - unmaintained packages are not an Emacs-sp= ecific issue and they exist in every programming community. I don't real= ly think we need some special policy on handling them, as:

- if a package is really valuable new maintainers will a= lways be found
- if something is in a really bad state peo= ple will just stop using it

Spending our li= mited efforts on policing the ELPA packages and trying to decide if some= thing is "properly maintained" is not going to amount to much IMO. If so= meone uses a package and thinks it's valuable then it probably is. A pac= kage 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 improv= e their state - that's a completely different topic.

=
On Wed, Jun 1, 2022, at 1:08 AM, Jo=C3=A3o T=C3=A1vora wrote:=
On Tue, May 31, 2022, 17:42 Philip Kaludercic &l= t;philipk@posteo= .net> wrote:
To be specific, my issue was mentioned here:
false-positives when exp= anding snippets").  In my case, I have managed
to ci= rcumvent 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-hour= s 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 coul= d be questioned.
You don't have to sugar-coat it. Yasnippet's bu= g 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 a= nymore. 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 mi= ght not be doing what you want.  I understand that.


In t= hat sense, it'd be nice if yasnippet wasn't' the monolithic package it i= s,
and 'snippet.el' is a step in that direct= ion.  Then you could perhaps opt out
(o= r in) to the multi-file, keybinding, abbrev-like functionality of yasnip= pet.el. 
Or simply compose 'snippet.el'= bare-bones expansion/navigation with
whatev= er 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'.

<= div dir=3D"auto">
> Is it just the = general idea of abandonment of the fact that people's
>= ; issue reports go unanswered?  If the latter, then I think archivi= ng to
> the repo would make sense.  No more issue= reports would come in and
> one could advertise the E= macs bug tracker.  Would that improve things?

I guess, but I think it would be preferable to call for someon= e to fork
the package instead of shifting the burden of m= aintenance onto the emacs
bug tracker.

Again, i d= on't quite understand how that magically solves the root problem
You're free to fork when you want, of course, but th= at normally happens
when you want to take th= e software in a new irreconcilable new direction.

Currently, yasnippet just needs (1) a m= aintainer that understands the
current funct= ionality and "protects" it, fixing bugs, not introducing new ones.
New features are probably not a great idea. (2) so= meone to develop 'snippet.el'
into productio= n-ready state and make 'yasnippet.el' depend on it, then may
<= div dir=3D"auto">integrate make 'snippet.el' into a new package. The per= son 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
t= his.

Great, if you're serious = about it drop me a line stating more or less what
your pla= n 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=C3=A3o

PS: in the meanti= me, it seems that Dmitry suggested what seems like a
reas= onable way to address your request.



--fb85c3a9fadc4ca6bd53215d56744b3d--