Re: Moving Gnus development to Emacs

[Ivan Shmakov <ivan@siamics.net>]

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