Re: Moving Gnus development to Emacs?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

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