emacs-devel
[Top][All Lists]
Advanced

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

Re: Moving Gnus development to Emacs


From: Steve Youngs
Subject: Re: Moving Gnus development to Emacs
Date: Thu, 31 Dec 2015 00:33:26 +1000
User-agent: Gnus/5.130014 (Ma Gnus v0.14) SXEmacs/22.1.15 (Goggomobil, linux)

Lars Magne Ingebrigtsen <address@hidden> writes:

  > (Excuse the crossposting.)

No problem.  Apologies for my list bouncing you. I've tweaked my mailman
settings so subsequent messages shouldn't get discarded (fingers crossed)

  > Back in the olden days, there were basically two reasons for doing
  > the Gnus development outside of Emacs: 1) Emacs was releasing very
  > slowly, and Gnus very fast, and 2) XEmacs was an important target
  > for development.

  > 1) is not true any more.  And XEmacs isn't as vital as it used to be.

Yep, I'll certainly give you that.  The advantage/benefits I see to
having the Gnus code base reside outside of Emacs is that (S)XEmacs Gnus
hackers don't need to have a copy of Emacs checked out just to hack
Gnus.  And I'm sure that there are plenty who'd like to hack/use dev
Gnus from stable Emacs.

  > And the SXEmacs peeps just started maintaining their own Gnus repo,

Wow, news gets around fast. :-)  I gotta admit though that I wasn't
planning on doing anything large scale with that.  Just the odd tweaks
to keep it build-able and run-able. (partially motivated by apparent
stagnation in XEmacs packages)

  > which means that this might be a good opportunity to discontinue the
  > git.gnus.org repo and just continue development on the Emacs trunk
  > instead.

  > Emacs has developed rapidly during the last few years, and the
  > interfaces between Emacs, older versions of Emacs, and XEmacs are
  > growing more divergent.  This means that basically any change we do in
  > Gnus fails to build on all build targets.  And this, in turn, means that
  > any change we do in Gnus is 2x as much work as it should be, and this
  > leaves the code looking like an exercise in obfuscated programming.
  > Sometimes.  :-)

But this has nothing to do with _where_ the canonical source repo is,
and everything to do with _which_ emacsen you want to support.

  > So: I want to know how all y'all would feel if I closed git.gnus.org and
  > started bringing the Gnus code base in the Emacs trunk up to modern
  > Emacs standards.

I'd feel sad, but I guess I could live with it.  I'm not sure how I
could keep my Gnus repo tracking your development if your stuff isn't in
its own repo, but I'll figure something out.

  > That would mean removing basically all compat code.

OK, from where I sit, this would totally suck. :-(  And anyone not
wanting to use dev Emacs would just have to put it all back in.

Any chance I could talk you out of it?  Is there a compromise?  Would it
be possible/acceptable to leave in the existing compat code but not
update it or use it for any new features from this point on? (I realise
this wouldn't be possible every time)

Or perhaps only remove the stuff that is currently proving to be trouble
spots for you (analogous to "If it ain't broke, don't fix it")?

I don't mind having to bring my own glue to get the lastest and greatest
shiny new feature working, but I don't want to glue stuff that has been
working fine for me for the last 15 to 20 years.

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<address@hidden>---|

Attachment: signature.asc
Description: PGP signature


reply via email to

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