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: New Package for NonGNU-ELPA: clojure-ts-mode Date: Sun, 27 Aug 2023 20:38:18 +0300 Message-ID: References: <87il9kksqz.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87wmxj27fn.fsf@dfreeman.email> <831qfrptiq.fsf@gnu.org> <57429221-d9be-5791-e975-b3539905e2f6@gutov.dev> <83a5udlj47.fsf@gnu.org> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <87il90znco.fsf@yahoo.com> <1977fbef-307b-bcf4-9448-64f26916dd65@gutov.dev> <87edjozlqq.fsf@yahoo.com> <43ddad10-49dd-1c49-ebfe-51689780b315@gutov.dev> <87msyciplu.fsf@posteo.net> <83h6okk3oe.fsf@gnu.org> <87edjoindn.fsf@posteo.net> <83bkesjwuk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=c74944b93f114f63a666ce624bc285c5 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31196"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.9.0-alpha0-647-g545049cfe6-fm-20230814.001-g545049cf Cc: dmitry@gutov.dev, luangruo@yahoo.com, danny@dfreeman.email, "Stefan Kangas" , "Emacs Devel" , "Manuel Uberti" To: "Eli Zaretskii" , "Philip Kaludercic" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 27 19:39:33 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 1qaJjX-0007wJ-Di for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 19:39:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaJiw-00024m-5O; Sun, 27 Aug 2023 13:38:54 -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 1qaJiq-00023u-62 for emacs-devel@gnu.org; Sun, 27 Aug 2023 13:38:48 -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 1qaJim-0004lJ-90; Sun, 27 Aug 2023 13:38:47 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 96A995C00FD; Sun, 27 Aug 2023 13:38:39 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Sun, 27 Aug 2023 13:38:39 -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=1693157919; x=1693244319; bh=87 9BLGeSBr99hJe6Faa1TPZsCewIvjFel5A4WIqDhEA=; b=RxOPkJ37N3Jh9wAbJX C0KTgfaa17LRKbr9PM8rJYagJKKq48ZcLjNNZ28gkyc8VncJ8Zcj/CWRJ5Nn/I1s OPnlcT+S/jrmTL20/+6MwSH3OJE1s8UWpyxTeSaLitrXlkgCKns1WODR1Ej+Icug ia+BoP9rCBosVPkBsyxcPLYPu3Mh6+WtSzjke2szu8Io0pUJSEOU/DbKwyi02hjY BCeCRl0HOE9Qhdrp/3Ajq7VU9elP92933EbZ/xnrdN41lZRA5eibA6eS+Jjg79WU 9v3hPi307fFz6zFpCJGOkFs9alzPLv20Ke0JfEpbLw3dGnL8hHo9ipl3EgpQhYY+ 5cgQ== 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=1693157919; x=1693244319; bh=879BLGeSBr99h Je6Faa1TPZsCewIvjFel5A4WIqDhEA=; b=bBtYDYqfJ00V4LapB7HxeoROfk0LX sHBzz1Mp6mDQu3OORAaxvscq5Hciqx/Km/fMai2O/yixey13M+hfQOC/PpqzAOQ0 BSgSYuN2yT6TzDC0zg95OzN7PcGDDVRoTqZ4kVr8ISnIddgG+tVPOTpHWhgna3Ux IHDmorvBR+Gby3Q3/hdIWGPgDyNWi4w8uTqGbse8+eWt+UM+8wJ2kNopyyHfo1PZ 8tvbTeKDytG8whMrb+ZmW+uCLxEZBYPRQfNO+GwJ3qm59UvTxPI56CfHNhoUqiWh 2kJ/FpRvuhsGjvpo5w1DDBmvrQs3gBRijKMQdHi2re2r0AvdW2+mO7oMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreertdenucfhrhhomhepfdeu ohiihhhiuggrrhcuuegrthhsohhvfdcuoegsohiihhhiuggrrhessggrthhsohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeeftdekgfdvgfehueffheejudehkefgffffheektdet vdejgfelheeiiefhffffgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegsohiihhhiuggrrhessggrthhsohhvrdguvghv X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7CAE12D40092; Sun, 27 Aug 2023 13:38:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <83bkesjwuk.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:309358 Archived-At: --c74944b93f114f63a666ce624bc285c5 Content-Type: text/plain I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed. All the other Clojure modes are on NonGNU ELPA already (clojure-mode, CIDER, inf-clojure, etc), so let's avoid philosophical discussions about the merits of X, Y and Z and just get this done, please. On Sun, Aug 27, 2023, at 7:04 PM, Eli Zaretskii wrote: > > From: Philip Kaludercic > > Cc: dmitry@gutov.dev, luangruo@yahoo.com, danny@dfreeman.email, > > stefankangas@gmail.com, emacs-devel@gnu.org, > > manuel.uberti@inventati.org > > Date: Sun, 27 Aug 2023 14:13:56 +0000 > > > > Eli Zaretskii writes: > > > > >> From: Philip Kaludercic > > >> Cc: Po Lu , Eli Zaretskii , > > >> danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, > > >> manuel.uberti@inventati.org > > >> Date: Sun, 27 Aug 2023 13:25:49 +0000 > > >> > > >> BTW. what is the current system by which releases are cut? I don't know > > >> if the maintainers have a schedule or some general plan for internal > > >> usage. > > > > > > I don't know how to answer this. > > > > How did you decide when to draw the line between Emacs 29 and Emacs 30? > > That's when the release branch is cut. But doing so doesn't determine > the future release date, except very roughly. > > When to cut the release branch is up to the maintainers, and IME the > reasons are not fixed. The mount of new features and the time since > the last major release are important factors, though. > > > > And why should we take them into account, and not the > > > other way around? I have never seen a Debian (or any other distro) > > > approach us asking when the next release is expected. > > > > That is true, but I don't see any reason why there shouldn't be any > > cooperation. > > Neither do I, but cooperation is a two-way street. > > There's also a problem that we rarely can promise a certain release > date, because there are factors out of our control, such as the bugs > and regressions reported during pretest, the resources that can > dwindle due to "Real Life", etc. > > --c74944b93f114f63a666ce624bc285c5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I believe this = conversation has drifted a lot from the original topic (clojure-ts-mode)= . I have to say I'm a bit frustrated that every time someone wants to su= bmit something to NonGNU ELPA there's some push to either submit to GNU = ELPA or core instead. I've been maintaining almost all of the Clojure de= v tooling for Emacs for over a decade, so I do believe that by now I kno= w what I'm doing and how I want to do things. I've said a million times = by now that I don't want contributors to have to deal with copyright agr= eements and with quirks/oddities in the Emacs development process. I bel= ieve that the maintainers who actually work on something should be allow= ed to decide how their projects get developed.
=

All the other Clojure modes are on NonGNU ELPA= already (clojure-mode, CIDER, inf-clojure, etc), so let's avoid philoso= phical discussions about the merits of X, Y and Z and just get this done= , please.

On Sun, Aug 27, 2023, at 7:04 PM= , Eli Zaretskii wrote:
> From: Philip Kaludercic <philipk@posteo.net>
>   manuel.uberti@inventati.org
> Date: Sun, 27 Aug 2023 14:13:56 +0000
> = ;
> Eli Zaretskii <e= liz@gnu.org> writes:
> 
> = >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: Po Lu <= luangruo@yahoo.com>,  = Eli Zaretskii <eliz@gnu.org>,<= br>
> >> Date: Sun, 27= Aug 2023 13:25:49 +0000
> >> 
> >> BTW. what is the current system by which releases are cut= ?  I don't know
> >> if the maintainers have= a schedule or some general plan for internal
> >>= ; usage.
> >
> > I don't know ho= w to answer this.
> 
> How did yo= u decide when to draw the line between Emacs 29 and Emacs 30?
<= div>
That's when the release branch is cut.  But doin= g so doesn't determine
the future release date, except ver= y roughly.

When to cut the release branch i= s up to the maintainers, and IME the
reasons are not fixed= .  The mount of new features and the time since
the l= ast major release are important factors, though.

> >         &nb= sp;    And why should we take them into account, and not = the
> > other way around?  I have never seen a = Debian (or any other distro)
> > approach us asking = when the next release is expected.
> 
> That is true, but I don't see any reason why there shouldn't be a= ny
> cooperation.

Neither = do I, but cooperation is a two-way street.

= There's also a problem that we rarely can promise a certain release
<= /div>
date, because there are factors out of our control, such as th= e bugs
and regressions reported during pretest, the resour= ces that can
dwindle due to "Real Life", etc.



--c74944b93f114f63a666ce624bc285c5--