Re: why so many emacs version packages?

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%NetBSD.org@localhost> writes:

BLUF:

  - We should remove emacs-snapshot, more or less immediately (ok with
    me during freeze), as
      + trying to do what wip/emacs-git actually does
      + unmaintained for years
      + building tip of upstream VCS not super appropriate in pkgsrc main
        unless upstream is deficient at actually having releases (which
        emacs is not!)
      + so old that surely nobody is using it

  - I see no reason for emacs26 and emacs27 to continue to exist, and
    someone(tm) should issue a removal proposal, for deletion after the
    branch.  I see no urgency for the branch.

  - The DESCRs for emacs20/emacs21 should in the last paragraph where it
    says that they are 20/21 say something about why someone might want
    to run them vs 29.

  - I see no issue with the one-behind version being in pkgsrc,
    currently 28.

  - Perhaps emacs30 in wip, along the branch pre-release, would be nice
    (but personally I am happy to follow along and not work on emacs!).

> I'm wondering what the point of all the emacs versions is that we have
> in pkgsrc.

It is a good question and IMHO the DESCR should explain this by
explaining the reason, at least for very old.

> emacs20

dholland MAINTAINS this and I think cares about a semi-small emacs on
underpowered machines.

> emacs21

Not sure but I think has some sort of old-machine-support belief.  (I'm
not saying I concur.)

> emacs26
> emacs27
> emacs28
> emacs29

I think we have been adding them as versioned (because if any are
versioned all should be), and people(tm) are just slow on removals.

I think it makes sense to have two because updating emacs does cause
wrinkles and given that we have more than one, letting people decouple
updates slightly is nice.

I have over the last quarter moved from 28 to 29, personally.  I did
find an annoyance in 28 or 29, but not enough to hold me back, and now I
don't remember it.  But I know it annoys me at least once a week.

I think we should rm emacs26 and emacs27.
  (I'm not anxious to do this during the freeze, because it isn't
  actually broken, everything has risk, we're about to branch, and a
  removal proposal needs time.)

> emacs-snapshot (which is currently older than emacs29)

It is perhaps reasonable to have this, and perhaps not.   I don't see
building from upstream VCS to be sensible in pkgsrc, for packages that
have releases.  I think it's  totally fine in wip.   If upstream moves
fast enough, using the VCS version from the latest branch doesn't make
sense.   And if it's older then emacs29, that's a clue that nobody
cares.

We have emacs-git in wip, which seems to be "build the latest from
upstream VCS", so I think it's ok to gc emacs-snapshot, more or less
without discussion.

> and two xemacs versions:
>
> xemacs
> xemacs-current

I have never been a fan of xemacs, but always perceived that as my
preference.   It seems that it is different enough that if people want
to have it in pkgsrc, I can't make even the slightest argument that they
shouldn't.  I do not think xemacs is confusing vs emacs, for people that
use emacs.

Apparently xemacs is being maintained, which was a surprise, and as I
read the pkgsrc bits, xemacs is the most recent stable release -- even
if it is many many years old -- and xemacs-current is the most recent
unstable release.

So other than DESCR of xemacs* not explaining what they are about (and
MESSAGE existing :-(), those packages seem ok and I see them as out of
scope for a "why do we have so many emacs packages".