Re: Moving Gnus development to Emacs

[Ivan Shmakov]

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