[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving Gnus development to Emacs
From: |
Ivan Shmakov |
Subject: |
Re: Moving Gnus development to Emacs |
Date: |
Wed, 30 Dec 2015 15:15:41 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
>>>>> Steve Youngs <address@hidden> writes:
>>>>> Lars Magne Ingebrigtsen <address@hidden> 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
- Moving Gnus development to Emacs?, Lars Magne Ingebrigtsen, 2015/12/30
- Message not available
- Re: Moving Gnus development to Emacs?, Eli Zaretskii, 2015/12/30
- Re: Moving Gnus development to Emacs?, raman, 2015/12/30
- Re: Moving Gnus development to Emacs?, Nikolaus Rath, 2015/12/30
- Re: Moving Gnus development to Emacs?, John Wiegley, 2015/12/30
- Re: Moving Gnus development to Emacs?, Katsumi Yamaoka, 2015/12/30
- Re: Moving Gnus development to Emacs?, Julien Danjou, 2015/12/31
- Re: Moving Gnus development to Emacs?, David Engster, 2015/12/31