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: Brand new clojure support in Emacs ;-) Date: Sun, 03 Sep 2023 22:59:46 +0200 Message-ID: <78d9400d-c386-41ed-8914-a109ed79280c@app.fastmail.com> References: <87il9kksqz.fsf@dfreeman.email> <87a5uw9ivs.fsf@posteo.net> <87ttt42gna.fsf@dfreeman.email> <87wmy080kn.fsf@posteo.net> <83v8djcydl.fsf@gnu.org> <87350ndquw.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87zg2hsyrd.fsf@dfreeman.email> <87h6ontwfv.fsf@posteo.net> <87r0nlngmo.fsf@posteo.net> <2d6a9558-4a4f-47e8-9122-62c7665e5f73@app.fastmail.com> <87ledn1dyu.fsf@posteo.net> <8bf9ac13-d620-4b5c-8e03-de21c4d85506@app.fastmail.com> <83cyyz6y02.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f9ee51add04d47258a69a67936401950 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="737"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.9.0-alpha0-701-g9b2f44d3ee-fm-20230823.001-g9b2f44d3 Cc: "Philip Kaludercic" , =?UTF-8?Q?Jo=C3=A3o_T=C3=A1vora?= , "Richard Stallman" , "Danny Freeman" , "Emacs Devel" , "Manuel Uberti" To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 03 23:01:01 2023 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 1qcuDL-000AUh-NG for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Sep 2023 23:01:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcuCf-00081C-SO; Sun, 03 Sep 2023 17:00:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcuCa-0007zf-Rm for emacs-devel@gnu.org; Sun, 03 Sep 2023 17:00:13 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcuCX-00052f-Ls; Sun, 03 Sep 2023 17:00:12 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B09A65C0106; Sun, 3 Sep 2023 17:00:07 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Sun, 03 Sep 2023 17:00:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :cc:content-type: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=1693774807; x=1693861207; bh=kV 5Qr47KnTVujGtnaHXvn31Whp/ys9S+4L//tNE230Q=; b=o4ioHztDCPqta0fw8K 4s6sichMcUhxTrgq8Ftmx3HoViHR/jg4+CoTwABPko7MH59SggcA5aYxI+rfnqF3 BKq1q+RHm7GqcgxStM98Ymq2zjshJmGYrBWt2uINhc4lPwI+ZkRVvJ1zl/AKWfDB 2thufm++ZL1qpjE5W+8qahNGay1wwgdpIlJ494ab1pc8yunRF6u8RX1xiAI2pZBb MRmXDBVfNQcDkNqM00lkjQv7aD5AJ8rPV6pi2UQAUorTslP8zj1JYpYr0PtS5OCc WP/OKrA9YFEz7J/N7rgcfPpEz3jrYx80XQozl9m3Wg+J4FSJt4dWPg71ytxSql0b 0rzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type: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=1693774807; x=1693861207; bh=kV5Qr47KnTVuj GtnaHXvn31Whp/ys9S+4L//tNE230Q=; b=Z7SM7d6IHBl5uecNMZDA033pbuyNe 5D42qFBGX2Q1w29ui+6NU40qin47KeTGH6J6K79xRUhCC4hDKWNG2xeaXgcnGEcg h5etnbG/S8Yxj/7Ht6f490b5O0bJlIKJXCVLUISeAaY/SdobOHbErwUxFzcbWzhT 1/52j2emJbiEqwGrdjx13DN7TbHZN0oKs+JG3d55jY5CDhz1htheFySY/0k8U0SW m3lpze3LOarEAHBvsuIeH0/XvWmhc8BDJ1DEY8Bp8uRD4RLk+PrJcr0buch2j896 5kuBLrBE+f9xdb5RZ06nxwLx7NoOP7fkKYOSsPPhkXKzqxmm5C429GhDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudegiedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdeu ohiihhhiuggrrhcuuegrthhsohhvfdcuoegsohiihhhiuggrrhessggrthhsohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeevvdeihfdtuedvleduteefgefhueegueelhffgtefh hfelgfegheelffefhfdvffenucffohhmrghinheptghorhgvrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoiihhihgurghrsegs rghtshhovhdruggvvh X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 022532D40092; Sun, 3 Sep 2023 17:00:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <83cyyz6y02.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.27; envelope-from=bozhidar@batsov.dev; helo=out3-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 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310026 Archived-At: --f9ee51add04d47258a69a67936401950 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable That's good to hear and it sounds fairly reasonable to me. I'm guessing = that the hardest part will be getting everyone to sign the CA, as there = were quite a few contributors over the years. (and ideally we'll need so= me simple way to get new contributors to sign the CA - I'm not sure what= 's the process these days) =20 One more thing that came to mind is how are we going to deal with update= s of package that happen between Emacs major releases. I'm guessing that= clojure-mode should also be available on GNU ELPA, so users can update = to the latest version, right?=20 If you don't mind - I'd like to ask to put the topic on hold for a bit h= ere, so I can discuss it properly with the other members of clojure-emac= s and hear how they feel about it. If you truly believe that it'd be imp= ortant to include clojure-mode in Emacs we'll consider this carefully. I= hope you'll agree that's not super time sensitive and there's no need t= o make hasty decisions.=20 Despite the unpleasant tone of the conversation at times, I'm trying to = keep an open mind here and I appreciate everyone who has provided some c= onstructive opinions to the discussion.=20 On Sun, Sep 3, 2023, at 6:07 PM, Eli Zaretskii wrote: > > Date: Sun, 03 Sep 2023 17:37:07 +0200 > > From: "Bozhidar Batsov" > > Cc: Jo=C3=A3o T=C3=A1vora , > > "Richard Stallman" , "Danny Freeman" , > > "Eli Zaretskii" , "Emacs Devel" , > > "Manuel Uberti" > >=20 > > - where are issues reported? I don't want to use the Emacs issue tra= cker, but that'd be unavoidable > > for something built-in, so instead of having one issue tracker you e= nd up with two (one of which I > > really dislike) >=20 > There's no requirement to use debbugs for your package, even if it is > in core. Org, for example, doesn't. When people submit bug reports > about Org to debbugs, we redirect them to the Org list. >=20 > > - some patches will be submitted on GitHub, some on emacs-devel - I = highly doubt that all the > > clojure-mode maintainers would be willing to deal with this >=20 > Same here: there's no requirement to have patches submitted directly > to us. Quite the contrary: as long as you and your colleagues > actively develop and maintain the package, we'd prefer that patches > are first reviewed by you. >=20 > > - discussions related to problems/ideas would be happening in differ= ent places >=20 > Again, not a requirement. But yes, the developers should be available > on emacs-devel, because issues could pop up here. You could have a > representative, though, not all of you. >=20 > > - there's also so overhead of keeping the GitHub repo and the code i= n Emacs in sync >=20 > Ihor and others should correct me, but what overhead do you have in > mind? We already have a few packages that are basically developed > outside of Emacs and only merged with Emacs from time to time, so you > will not be the first package to go that way. >=20 > > I can go on and on about this - hybrid development models simply com= e with a lot of overhead. I get > > that here many people think that GitHub is the root of all evil, but= political preferences aside - it's the > > largest forge in the world by a huge margin and I think it provides = unique benefits to projects that > > can't be replicated elsewhere. At least not today.=20 >=20 > I think the difficulties are not as great as you imagine. And our > opinions about GitHub are not relevant if the package is regularly > merged into emacs.git. >=20 >=20 --f9ee51add04d47258a69a67936401950 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
That's good to = hear and it sounds fairly reasonable to me. I'm guessing that the hardes= t part will be getting everyone to sign the CA, as there were quite a fe= w contributors over the years. (and ideally we'll need some simple way t= o get new contributors to sign the CA - I'm not sure what's the process = these days) 

One more thing that came= to mind is how are we going to deal with updates of package that happen= between Emacs major releases. I'm guessing that clojure-mode should als= o be available on GNU ELPA, so users can update to the latest version, r= ight?

If you don't mind - I'd like to ask = to put the topic on hold for a bit here, so I can discuss it properly wi= th the other members of clojure-emacs and hear how they feel about it. I= f you truly believe that it'd be important to include clojure-mode in Em= acs we'll consider this carefully. I hope you'll agree that's not super = time sensitive and there's no need to make hasty decisions.

Despite the unpleasant tone of the conversation at tim= es, I'm trying to keep an open mind here and I appreciate everyone who h= as provided some constructive opinions to the discussion.

On Sun, Sep 3, 2023, at 6:07 PM, Eli Zaretskii wrote:
> Date: Su= n, 03 Sep 2023 17:37:07 +0200
> From: "Bozhidar Batsov"= <bozhidar@batsov.dev><= br>
> Cc: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>,
>  = "Richard Stallman" <rms@gnu.org>= ;, "Danny Freeman" <danny@dfr= eeman.email>,
>  "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>,
<= div>>  "Manuel Uberti" <manuel.uberti@inventati.org>
> - where are issues reported? I don't want to use the E= macs issue tracker, but that'd be unavoidable
> for som= ething built-in, so instead of having one issue tracker you end up with = two (one of which I
> really dislike)
There's no requirement to use debbugs for your package, even= if it is
in core.  Org, for example, doesn't.  = When people submit bug reports
about Org to debbugs, we re= direct them to the Org list.

> - some pa= tches will be submitted on GitHub, some on emacs-devel - I highly doubt = that all the
> clojure-mode maintainers would be willin= g to deal with this

Same here: there's no r= equirement to have patches submitted directly
to us. = Quite the contrary: as long as you and your colleagues
ac= tively develop and maintain the package, we'd prefer that patches
are first reviewed by you.

> - d= iscussions related to problems/ideas would be happening in different pla= ces

Again, not a requirement.  But yes= , the developers should be available
on emacs-devel, becau= se issues could pop up here.  You could have a
repres= entative, though, not all of you.

> - th= ere's also so overhead of keeping the GitHub repo and the code in Emacs = in sync

Ihor and others should correct me, = but what overhead do you have in
mind?  We already ha= ve a few packages that are basically developed
outside of = Emacs and only merged with Emacs from time to time, so you
will not be the first package to go that way.

<= div>> I can go on and on about this - hybrid development models simpl= y come with a lot of overhead. I get
> that here many p= eople think that GitHub is the root of all evil, but political preferenc= es aside - it's the
> largest forge in the world by a h= uge margin and I think it provides unique benefits to projects that
<= /div>
> can't be replicated elsewhere. At least not today. <= br>

I think the difficulties are not as great a= s you imagine.  And our
opinions about GitHub are not= relevant if the package is regularly
merged into emacs.gi= t.



--f9ee51add04d47258a69a67936401950--