Re: New Package for NonGNU-ELPA: clojure-ts-mode

["Bozhidar Batsov" <bozhidar@batsov.dev>]

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

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 <philipk@posteo.net>
> > 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 <eliz@gnu.org> writes:
> > 
> > >> From: Philip Kaludercic <philipk@posteo.net>
> > >> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
> > >>   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.
> 
> 

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