Moving Gnus development to Emacs?

Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

(Excuse the crossposting.)

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.

And the SXEmacs peeps just started maintaining their own Gnus repo,
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.  :-)

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.  That would mean removing basically all compat code.

No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs

[Steve Youngs]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> 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!          |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 404 bytes --]

Re: Moving Gnus development to Emacs

[Ivan Shmakov]

>>>>> Steve Youngs <steve@sxemacs.org> writes:
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

[…]

 > 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.

	The converse is also true: moving Gnus into a separate Git
	submodule would allow those of the Emacs developers not
	interested in Gnus /not/ to check it out.  And while I’m not in
	that group, there’re several large Emacs packages which I’d
	find convenient /not/ to have in the checkouts I work with.

	Sadly, there seem to be a general consensus among the GNU
	developers to avoid any use whatsoever of Git submodules.
	The issues with this approach include the impossibility for a
	single commit to span several submodules; and I guess having the
	tests run on the whole Emacs tree helps to weed out the changes
	that should not be.

 >> 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.

	Yes.

[…]

 >> 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.

	Given that two concurent branches of Emacs are generally
	maintained (master and emacs-25 currently), there’s a fair
	chance that the users of the latest point release will still be
	entitled to try the latest Gnus – from the respective branch.
	But yes, all the major features would likely only be available
	for the ‘master’ (Gnus, Emacs) version.

 > 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)

	Whatever this discussion will end on, I guess it’d still be
	possible to move the compatibility code into the XEmacs Gnus
	“port” and maintain it there.

[…]

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Re: Moving Gnus development to Emacs

[Steinar Bang]

>>>>> Steve Youngs <steve@sxemacs.org>:

> 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.

There is "git subtree split", but it looks like it requires the use of
--squash, which seriously diminishes its usefulness (in my opinion).

Re: Moving Gnus development to Emacs

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

>   > 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)

Having different programming styles in the same functions is just
awkward.  One talks about `gnus-union' and the other talks about
`cl-union' (or whatever).  Somebody who tries to fix a bug will have to
examine `gnus-union' to see whether it does something weird, and then
discover that it's just the normal `cl-union'.

It's doable, of course, but it's not very readable.

> 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.

Well, Gnus will still be working for you, but new features will have to
be ported gingerly, I'm afraid...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[raman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

This would be nice!> (Excuse the crossposting.)
>
> 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.
>
> And the SXEmacs peeps just started maintaining their own Gnus repo,
> 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.  :-)
>
> 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.  That would mean removing basically all compat code.
>
> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

-- 

Re: Moving Gnus development to Emacs?

[Jay Belanger]

raman <raman@google.com> writes:
...
> This would be nice!> (Excuse the crossposting.)

Why?

>> 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.  That would mean removing basically all compat code.

These are three different issues, right?

Not including new compat code is one thing, but why remove what is
already there?

How is the Gnus code base not up to modern standards?  Why would 
bring it up to snuff require removing compat code?

And these two issues can be dealt with regardless of where the Gnus
development occurs; moving it to the Emacs trunk means only people 
running git Emacs can use/work on the latest Gnus.

Re: Moving Gnus development to Emacs?

[Nikolaus Rath]

On Dec 30 2015, Jay Belanger <jay.p.belanger@gmail.com> wrote:
> Not including new compat code is one thing, but why remove what is
> already there?

Because it makes it way easier for people new to the code to contribute.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Not including new compat code is one thing, but why remove what is
> already there?

It's a maintainability issue.  You kinda have to be a Gnus expert to fix
even rather trivial bugs in Gnus now because there's so much
back-and-forth between various compat functions that (sometimes) vaguely
do not work as you'd expect.

> How is the Gnus code base not up to modern standards?

`when-let', seq-*, `pcase', cllib, and of course the big incompatible
thing that's difficult to fix with compat functions: Lexical binding.

> And these two issues can be dealt with regardless of where the Gnus
> development occurs; moving it to the Emacs trunk means only people 
> running git Emacs can use/work on the latest Gnus.

True, but building git Emacs is so ridiculously easy on modern GNU/Linux
systems that that's what I'd recommend anyway:

$ sudo apt-get build-dep emacs24
$ git clone git://git.savannah.gnu.org/emacs.git
$ cd emacs
$ make

That's less work than fetching Gnus, compiling and adjusting
`load-path'...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[Benjamin Slade]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Jay Belanger <jay.p.belanger@gmail.com> writes:
>> And these two issues can be dealt with regardless of where the Gnus
>> development occurs; moving it to the Emacs trunk means only people 
>> running git Emacs can use/work on the latest Gnus.
>
> True, but building git Emacs is so ridiculously easy on modern GNU/Linux
> systems that that's what I'd recommend anyway:
>
> $ sudo apt-get build-dep emacs24
> $ git clone git://git.savannah.gnu.org/emacs.git
> $ cd emacs
> $ make
>
> That's less work than fetching Gnus, compiling and adjusting
> `load-path'...

I end up not running git Emacs myself because there end up being lots of
bits that don't work. But it's nice to be able to run git versions of
particular packages (like Gnus).

Re: Moving Gnus development to Emacs?

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> 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. That would mean removing basically all compat code.

Sounds great to me.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

That's great.  I'm ok to move the gnus-doc-ja repo to github or
something when closing git.gnus.org.

Re: Moving Gnus development to Emacs?

[Eli Zaretskii]

> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Date: Thu, 31 Dec 2015 09:46:41 +0900
> Cc: yamaoka@jpl.org, sxemacs-devel@sxemacs.org, emacs-devel@gnu.org
> 
> I'm ok to move the gnus-doc-ja repo to github or something when
> closing git.gnus.org.

Why cannot gnus-doc-ja be part of Emacs as well?

Re: Moving Gnus development to Emacs?

[Julien Danjou]

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

On Wed, Dec 30 2015, Lars Magne Ingebrigtsen wrote:

> 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.  That would mean removing basically all compat code.

No objection sir.

-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

Re: Moving Gnus development to Emacs?

[David Engster]

Lars Magne Ingebrigtsen writes:
> 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.  That would mean removing basically all compat code.

No objections from me (I'm currently doing the same for CEDET, for
pretty much the same reasons), but just to clarify: this means that we
only care about the current Emacs version and do not do separate
releases anymore? I'm mostly worried about how this will affect the
T-shirt release process.

-David

Re: Moving Gnus development to Emacs?

[Michael Albinus]

David Engster <deng@randomsample.de> writes:

> No objections from me (I'm currently doing the same for CEDET, for
> pretty much the same reasons), but just to clarify: this means that we
> only care about the current Emacs version and do not do separate
> releases anymore? I'm mostly worried about how this will affect the
> T-shirt release process.

Tramp will also remove the XEmacs compat code (and the compat code for
Emacs 22, to be precise). But the development will still be outside
Emacs, in order to support older Emacsen but master, and in order to
release more frequently than Emacs. One idea is to add Tramp also to
ELPA, as subtree. People could get than a newer version of Tramp than
the built-in.

This decision is not T-shirt driven, I fear the market for Tramp
T-shirts is much too small.

> -David

Best regards, Michael.

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Thu, 31 Dec 2015 12:43:06 +0100
* Also sprach Michael Albinus <michael.albinus@gmx.de>:

> David Engster <deng@randomsample.de> writes:
>
>> No objections from me (I'm currently doing the same for CEDET, for
>> pretty much the same reasons), but just to clarify: this means that
>> we only care about the current Emacs version and do not do separate
>> releases anymore? I'm mostly worried about how this will affect the
>> T-shirt release process.
>
> Tramp will also remove the XEmacs compat code (and the compat code for
> Emacs 22, to be precise). But the development will still be outside
> Emacs, in order to support older Emacsen but master, and in order to
> release more frequently than Emacs. One idea is to add Tramp also to
> ELPA, as subtree. People could get than a newer version of Tramp than
> the built-in.

John talked about new trend to move more codes into ELPA.
Maybe it's THE RIGHT WAY, to make emacs as emacs-core (with only bare
functions) and all others packges (core as ELPA, third party as Melpa
etc, or even PPA). If package.el becomes APT like, that'll be cool,
really cool.

Re: Moving Gnus development to Emacs?

[Xue Fuqiao]

On Thu, Dec 31, 2015 at 8:29 PM, CHENG Gao <chenggao@royau.me> wrote:

> John talked about new trend to move more codes into ELPA.
> Maybe it's THE RIGHT WAY, to make emacs as emacs-core (with only bare
> functions) and all others packges (core as ELPA, third party as Melpa
> etc, or even PPA).

FYI - there were some discussions about this proposal earlier this year:

* https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00212.html
* https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00146.html

IIRC Atom is using this kind of architecture.  It has a really basic
core, and most of its features are available as packages, including some
very "basic" features, like settings-view (similar to `M-x customize' in
Emacs), find-and-replace, status-bar (similar to mode line in Emacs),
tabs (GUI tabs, not the tab character), language modes, etc.

But this approach also has its downside.  See the links above for some
related discussions.

> If package.el becomes APT like, that'll be cool, really cool.

What does this mean?  Command-line tools like `apt', `apt-get' or
`apt-cache' (or `apm' in Atom)?  If so, I think a simple wrapper script
to `emacs --batch' is enough.

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Thu, 31 Dec 2015 22:35:24 +0800
* Also sprach Xue Fuqiao <xfq.free@gmail.com>:

> On Thu, Dec 31, 2015 at 8:29 PM, CHENG Gao <chenggao@royau.me> wrote:
>
>> John talked about new trend to move more codes into ELPA. Maybe it's
>> THE RIGHT WAY, to make emacs as emacs-core (with only bare
>> functions) and all others packges (core as ELPA, third party as
>> Melpa etc, or even PPA).
>
> FYI - there were some discussions about this proposal earlier this
> year:
>
> * https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00212.html
> * https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00146.html
>
> IIRC Atom is using this kind of architecture. It has a really basic
> core, and most of its features are available as packages, including
> some very "basic" features, like settings-view (similar to `M-x
> customize' in Emacs), find-and-replace, status-bar (similar to mode
> line in Emacs), tabs (GUI tabs, not the tab character), language
> modes, etc.
>
> But this approach also has its downside. See the links above for some
> related discussions.

Thanks for the info. Yes I know Atom does this, and also VS Code recently.

>> If package.el becomes APT like, that'll be cool, really cool.
>
> What does this mean? Command-line tools like `apt', `apt-get' or
> `apt-cache' (or `apm' in Atom)? If so, I think a simple wrapper script
> to `emacs --batch' is enough.

I don't mean this. Sorry for my ambiguous expression.
Mainly I mean package.el can do dependency check and install proper
dependent packages. Also can handle different Emacs versions since
packages may stop supporting some Emacs versions or not yet catch up with
latest version. But it may be too complicated.

Re: Moving Gnus development to Emacs?

[Xue Fuqiao]

On Thu, Dec 31, 2015 at 10:52 PM, CHENG Gao <chenggao@royau.me> wrote:

>>> If package.el becomes APT like, that'll be cool, really cool.
>>
>> What does this mean? Command-line tools like `apt', `apt-get' or
>> `apt-cache' (or `apm' in Atom)? If so, I think a simple wrapper script
>> to `emacs --batch' is enough.
>
> I don't mean this. Sorry for my ambiguous expression.
> Mainly I mean package.el can do dependency check and install proper
> dependent packages. Also can handle different Emacs versions since
> packages may stop supporting some Emacs versions or not yet catch up with
> latest version. But it may be too complicated.

Thanks for the clarification.

Although I'm not quite familiar with both package.el and APT, AIUI
package.el can already do dependency check and handle different Emacs
versions.  You can use the "Package-Requires" header, for example:

   ;; Package-Requires: ((emacs "24.1") (cl-lib "0.5") (async "1.6"))

In Emacs 25, you can also use the command `package-autoremove' to remove
all packages which were installed strictly as dependencies but are no
longer needed, similar to `apt-get autoremove'.

Maybe I'm missing something, would you please explain?

PS: perhaps we should change the subject line of this subthread.

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Fri, 1 Jan 2016 08:10:34 +0800
* Also sprach Xue Fuqiao <xfq.free@gmail.com>:

> On Thu, Dec 31, 2015 at 10:52 PM, CHENG Gao <chenggao@royau.me> wrote:
>
>>>> If package.el becomes APT like, that'll be cool, really cool.
>>> What does this mean? Command-line tools like `apt', `apt-get' or
>>> `apt-cache' (or `apm' in Atom)? If so, I think a simple wrapper
>>> script to `emacs --batch' is enough.
>> I don't mean this. Sorry for my ambiguous expression. Mainly I mean
>> package.el can do dependency check and install proper dependent
>> packages. Also can handle different Emacs versions since packages
>> may stop supporting some Emacs versions or not yet catch up with
>> latest version. But it may be too complicated.
>
> Thanks for the clarification.
>
> Although I'm not quite familiar with both package.el and APT, AIUI
> package.el can already do dependency check and handle different Emacs
> versions. You can use the "Package-Requires" header, for example:
>
>    ;; Package-Requires: ((emacs "24.1") (cl-lib "0.5") (async "1.6"))
>
> In Emacs 25, you can also use the command `package-autoremove' to
> remove all packages which were installed strictly as dependencies but
> are no longer needed, similar to `apt-get autoremove'.
>
> Maybe I'm missing something, would you please explain?
>
> PS: perhaps we should change the subject line of this subthread.

Thanks for your detailed explanation. Good to know.
I read all posts in URLs you gave, and some others about use-package and
req-package etc. Seems future is expectable.

PS: Or I just stop here, be quiet and learn more.

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> No objections from me (I'm currently doing the same for CEDET, for
> pretty much the same reasons), but just to clarify: this means that we
> only care about the current Emacs version and do not do separate
> releases anymore?

Yup.

> I'm mostly worried about how this will affect the T-shirt release
> process.

I could still do code words and t-shirts.  Even though it's be cheating
slightly.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[Adam Sjøgren]

Lars writes:

> David Engster <deng@randomsample.de> writes:

>> I'm mostly worried about how this will affect the T-shirt release
>> process.

> I could still do code words and t-shirts.  Even though it's be cheating
> slightly.  :-)

Protest! It most certainly would not be. At all. Ahem.


  Not biased,

    Adam

-- 
 "God must've been punting angels left and right."            Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

After the discussion here, I think I've decided to move Gnus development
to Emacs and Emacsify the code for greater readability.

If {S,}XEmacs wants to keep tracking Gnus development, this
unfortunately means that the onus is on the {S,}XEmacs maintainers to
add an ever-growing number of Emacs compat functions, and expand
function call lists to keep up with Emacs function call lists.

(As well as adding seq/map/cllib/etc.)

The major stumbling block is, of course, lexical binding, but we'll see
how much of that creeps into Gnus after a while.  Gnus is quite async in
some respects, and having proper closures makes that a lot more
readable, but on the other hand, Gnus (ab)uses dynamic scope
extensively, so...

I wrote up the decision here, with added images:

http://lars.ingebrigtsen.no/2016/01/01/its-about-ethics-in-gnus-development/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> If {S,}XEmacs wants to keep tracking Gnus development, this
> unfortunately means that the onus is on the {S,}XEmacs maintainers to
> add an ever-growing number of Emacs compat functions, and expand
> function call lists to keep up with Emacs function call lists.

(FWIW this would be much easier for the {S,}XEmacs mainainers, if they
could do this on a separate branch in the Gnus repository.  It would be
the same lisp code issues but less git hassle...)

Re: Moving Gnus development to Emacs?

[Bill Wohler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> After the discussion here, I think I've decided to move Gnus development
> to Emacs and Emacsify the code for greater readability.

We moved MH-E to Emacs a few years ago. One welcome consequence of this
is that we have had more developers improving the code.

Lars, will you continue to have separate Gnus version numbers? Will you
move the bug tracker?

MH-E still maintains separate version numbers and we're still using
SourceForge for our bug tracking and a Git repository for MH-E files
that may not be appropriate for the Emacs repository (contrib, Debian
files, maintainers guide, web pages, tests, files for independent MH-E
releases).

Have you also considered moving Gnus to ELPA someday?

> If {S,}XEmacs wants to keep tracking Gnus development, this
> unfortunately means that the onus is on the {S,}XEmacs maintainers to
> add an ever-growing number of Emacs compat functions, and expand
> function call lists to keep up with Emacs function call lists.

We still have a small file with compatibility functions for older
Emacsen and XEmacs. It would be better if XEmacs provided the
compatibility so each package wouldn't have to.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Bill Wohler <wohler@newt.com> writes:

> Lars, will you continue to have separate Gnus version numbers? Will you
> move the bug tracker?

Gnus doesn't really have a bug tracker, per se, but just a Gnus bug
mailing list.  I won't be closing that address, but I'll be removing the
`gnus-bug' command and tell people to report all Gnus bugs with `M-x
report-emacs-bug' (which is how the majority of Gnus bugs are reported
today, anyway).

I think I'll have to keep doing Gnus version numbers -- otherwise, how
can I do t-shirts?

> Have you also considered moving Gnus to ELPA someday?

I think it's nice that Gnus just "is there" in Emacs...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think I'll have to keep doing Gnus version numbers -- otherwise, how can I
> do t-shirts?

I still have my Gnus mug from 1998.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Moving Gnus development to Emacs?

[Steve Youngs]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > After the discussion here, I think I've decided to move Gnus development
  > to Emacs and Emacsify the code for greater readability.

Are you going to keep git.gnus.org live for a period of time after the
move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?
Also, it'd be very much appreciated if you could let me know when the
last commit goes in at git.gnus.org.

  > If {S,}XEmacs wants to keep tracking Gnus development, this
  > unfortunately means that the onus is on the {S,}XEmacs maintainers to
  > add an ever-growing number of Emacs compat functions, and expand
  > function call lists to keep up with Emacs function call lists.

  > (As well as adding seq/map/cllib/etc.)

Yep, working on it. :)

  > The major stumbling block is, of course, lexical binding, but we'll see
  > how much of that creeps into Gnus after a while.  Gnus is quite async in
  > some respects, and having proper closures makes that a lot more
  > readable, but on the other hand, Gnus (ab)uses dynamic scope
  > extensively, so...

Gnus is far from unique in that (ab)use, even my own code does it a lot
more than I'd care to admit to.  But yeah, lexical scope is well and
truly on the SXEmacs radar.  Might have to bump it up a few notches on
the todo list. :-)

  > I wrote up the decision here, with added images:

  > http://lars.ingebrigtsen.no/2016/01/01/its-about-ethics-in-gnus-development/

It must be true, there's cats and memes involved.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 404 bytes --]

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

> Are you going to keep git.gnus.org live for a period of time after the
> move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?

Sure.  There's probably some way to switch it to read-only, I guess?

> Also, it'd be very much appreciated if you could let me know when the
> last commit goes in at git.gnus.org.

Will do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Wed, 06 Jan 2016 08:18:19 +0100
* Also sprach Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steve Youngs <steve@sxemacs.org> writes:
>
>> Are you going to keep git.gnus.org live for a period of time after the
>> move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?
>
> Sure.  There's probably some way to switch it to read-only, I guess?
>
>> Also, it'd be very much appreciated if you could let me know when the
>> last commit goes in at git.gnus.org.
>
> Will do.

Maybe have a new release and then move to ELPA.

By convention it should be a "lgnus. "Last" for "l" comes to my mind
irresistably.

Re: Moving Gnus development to Emacs?

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steve Youngs <steve@sxemacs.org> writes:
>
>> Are you going to keep git.gnus.org live for a period of time after the
>> move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?
>
> Sure.  There's probably some way to switch it to read-only, I guess?

If you swich off all authenticated access then nobody will be able to
push any more.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving Gnus development to Emacs?

[Ted Zlatanov]

On Sat, 02 Jan 2016 18:39:46 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> After the discussion here, I think I've decided to move Gnus development
LMI> to Emacs and Emacsify the code for greater readability.

Sorry for the late comment here, but I'm in favor.

Ted

Re: Moving Gnus development to Emacs?

[Greg Troxel]

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


Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> After the discussion here, I think I've decided to move Gnus development
> to Emacs and Emacsify the code for greater readability.

I see your point, but I think it's really unfortunate to not maintain
compatibility for at least the current actual release of emacs.  I
really don't like to run development snapshots of most things -- only a
few things that I decide it's worth the stability risk.  So basically
I'm suggesting maintaining compat for emacs 24 now, and when 25 is
released, maintaining 25 compat on the head of development.

This will make it easier for more people to track gnus development,
which I think will help gnus.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 180 bytes --]

Re: Moving Gnus development to Emacs?

[Eric Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (Excuse the crossposting.)
>
> 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.
>
> And the SXEmacs peeps just started maintaining their own Gnus repo,
> 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.  :-)
>
> 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.  That would mean removing basically all compat code.
>
> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

How much more work would it be to keep the external repo, but split the
different versions into different branches? Ie, an "emacs-master" branch
(which gets bundled into Emacs releases), an "Xemacs" branch, and an
"SXEmacs" branch (whatever that is).

That way everyone can be responsible for keeping their own version of
Gnus working with their own project, and can drop compatibility with
other people's projects. It's not like Gnus development is roaring ahead
at such a pace that the various branches are going to get significantly
left behind, right?

I'm probably letting my Git-ignorance show, but it seems like a single
independent repo where various people maintain their various branches
might end up being the cleanest solution.

E

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> That way everyone can be responsible for keeping their own version of
> Gnus working with their own project, and can drop compatibility with
> other people's projects. It's not like Gnus development is roaring ahead
> at such a pace that the various branches are going to get significantly
> left behind, right?

It requires that somebody does the job, though.  I think that probably
the SXEmacs people are up to it, and that's probably what they're going
to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving Gnus development to Emacs?

[Göktuğ Kayaalp]

On Thu, Dec 31 2015 at 12:15:32 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> […]
>> 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.  That would mean removing basically all compat code.
>>
>> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!
> How much more work would it be to keep the external repo, but split the
> different versions into different branches? Ie, an "emacs-master" branch
> (which gets bundled into Emacs releases), an "Xemacs" branch, and an
> "SXEmacs" branch (whatever that is).
> […]

Hi all, I'm a n00b to the list,  however I wanted to add my two cents to
the discussion.  Sorry if I say sth. silly.

If my memory is  good enough, I recall the new  GNU Emacs maintainer say
on a  recent interview [1] that  he wish to « modularise »  Emacs source
tree, i.e. move non-essential bits to their own projects.

I think vanilla  emacs bundles too many things, so  I back such attempt.
Installing packages in Emacs is very  easy today, one command is enough.
No need to bundle tetris, doctor,  etc., nor Org and Gnus.  Abrahamsen's
suggestion of branches seems good.  Alternatively, given that many Emacs
modules  begin   with  a  suit   of  /polyfills/,  maybe   a  standalone
/backports.el/ module should be created, so  that all the Elisp devs can
target  only  the  latest  release  without guilt.   Also  Gnus  can  be
developed  that way,  without  need to  maintain  /ports/ for  different
emacsen,  should a  good common  backports package  be available.   Gnus
releases target  the latest GNU  Emacs release,  and users of  older GNU
versions and  other emacsen  maintain the backports  package to  get the
cool  stuff.   This would  help  all  the  Emacs community.   Maybe  the
possiblity of this should be discussed on emacs-tangents.

[1] Sacha Chua's Emacs Chat with John Wiegley
    Video: <https://www.youtube.com/watch?v=nUjgKoOYxos>

All the best,
-gk

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/

Re: Moving Gnus development to Emacs?

[Uwe Brauer]

>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

   > (Excuse the crossposting.)

[...]


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

I see, you left xemacs-beta out in your newsgroup field...


   > 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. That would mean removing
   > basically all compat code.

Although I switched mostly to GNU emacs, that decision is a bit sad.
Could you at least tag the last Xemacs compat version, before removing
that code?