emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ihor Radchenko
Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode
Date: Thu, 31 Aug 2023 11:01:38 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> For Org, a number of people just update from ELPA. Releasing benefits
>> these users. 
>
> I don't see how is that different from updating from Git.

Not all the users are even familiar with Git. But every Emacs user is
expected to know how to M-x package-upgrade.

Getting Org (or Emacs) from Git would require non-trivial knowledge.
Even I fail to compile Emacs from sources when using non-familiar
distros like Debian.

>> > A minor release is more than just code with some bugs fixed: it (a)
>> > has no known bugs except those whose fix is too risky, and (b) was
>> > tested in the wild during a pretest.
>> 
>> You are right. To clarify: I am talking about _bugfix_ releases. Like
>> Org 9.6.7 -> 9.6.8. Emacs does not have those, currently.
>
> If bugfix releases just fix bugs, then basically every commit on the
> release branch is such a "release", because we only fix bugs there.

That's my point - get at least some bug fixes available to casual users
faster. Not on every commit, but with somewhat higher frequency compared
to "proper" minor releases.

> And don't forget that minor releases affect downstream distros: they
> need to package a new release, patch it, announce it, manage it, etc.
> It's very different from a single package, even a package that is as
> large as Org.

Sure. That's why I said that downstream packaging is the bottleneck that
should decide the acceptable bugfix release interval.

>> So, what about "bugfix" releases? AFAIU, it is mostly producing a
>> release tarball + waiting for Emacs to be packaged on major GNU/Linux
>> distributions. The timing would be anything acceptable for the latter
>> task, which appears to be a bottleneck in such scenario.
>
> That has only disadvantages from my POV: 2 hours of work to produce
> and test a tarball with no benefits at all.  If someone wants to
> volunteer to do that, fine.  (But then making a tarball by following
> the instructions in make-tarball.txt is easy, and anyone can do that
> for themselves if they want to.)

Can it be simply automated?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]