Re: Sync up the org in emacs master to org maint branch?

[David Engster <deng@randomsample.de>]

John Wiegley <jwiegley@gmail.com> writes:
>>>>>> "DE" == David Engster <deng@randomsample.de> writes:
>
> DE> So if you don't get convinced, we'll just move again, right? No big deal.
>
> I suppose I'm asking that of you, yes.

Sorry, but I rather wait.

> DE> You are insinuating that my motivation is to delegate CEDET development to
> DE> the core Emacs developers. This is simply not true, and I don't see how my
> DE> original mail could be interpreted like that.
>
> I didn't mean to insinuate anything; it seems we may have gotten off on the
> wrong foot, my intention is to make your life easier, not harder. If all this
> would do is make more work for people, it's not worth it.

This will most definitely make things harder for me. 

> DE> So let me try again: What I find completely misguided is to move packages
> DE> out of core *but still putting them into the release*. In other words, in
> DE> my opinion there are really just two options that make sense: you either
[+]
> DE> keep a package in core, or you kick it out and don't ship it with the
> DE> release.
>
> Why is this so? Right now I see the Emacs release as more than just releasing
> Emacs core; it's more of a "batteries included" release, combining the editor
> with lots of other default packages. It makes sense to me to move these
> batteries outside the core repository, than to put them all together in the
> same Git repository.

For package developers, keeping up with Emacs has become much harder in
recent years, as its development has accelerated (which is a good
thing). It's not like packages communicate with Emacs over a well
defined RESTful interface. In other words: CEDET and Gnus are not
loosely coupled, quite the opposite: they are extremely dependend on
many obscure Emacs internals (not sure about Org). As a consequence, we
and also the Gnus guys decided to not do separate releases anymore.  We
used to provide CEDET for different Emacs versions, and it was a *huge*
amount of work. I had a buildbot running with 7 or 8 Emacs versions to
run the test suite, and things broke pretty regularly.

Now you might say: fine, only release a package for current master. But
let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
Emacs 27 starts. Now there are changes happening in Emacs 27 that
require changes in CEDET, which make it incompatible with Emacs 26. So
you have to create two packages: one for 26, one for 27? Not only is
this confusing, but it most definitely increases my workload.

> We can arrange things so that a Git clone of Emacs includes pulling the
> submodules (or trees, or ELPA.git, or what not) that are considered part of
> "main Emacs development", including some of those batteries. I see this all as
> a process issue, and that "living in one Git repository" has just been an
> implementation strategy to satisfy that process.

Obviously, I'm very skeptical towards such an approach. Our tooling
around Emacs development is already very intricate and only works
because a few people work quietly behind the scenes to keep this all
running. Introducing even more complexity through
submodules/subtrees/whatever will do the opposite of what you want to
achieve: it creates more work for those few people who manage the Emacs
infrastructure. But I'd love to hear what for instance Glenn and Paul
think about this.

> Why do the split at all? Core becomes smaller,

First off, the Emacs repo isn't that big w.r.t. the number of
files. Secondly, while there surely is an inverse correlation between
repo size and maintainability, I would argue that as long as the Big
Three are well maintained, they are not the problem. When did CEDET,
Gnus or Org ever significantly delay an Emacs release?  When was an
Emacs core developer ever forced to fix a critical thing in those
packages he did not break?  These are the questions we should be
asking. From watching this list over the past years, I don't get the
feeling that the inclusion of these packages has been a significant
burden, but I may be wrong.

> its future history less cluttered,

That's actually a bit funny, since we gave up an uncluttered history
when we switched to git's spaghetti DAG.

> updating packages within it is no longer a major issue, and (I hope)
> it will be clearer when something is a core issue vs. a package issue.

I find this whole core vs package argument strange. If you ship Emacs
with Org, Gnus and CEDET, they are part of Emacs, so it's in the
interest of all Emacs developers that they work well, whether they use
them or not. The users won't care if they originate from a separate repo
and are considered a "package". So if Paul is determined to fix all
occurences of "compatilibity" in the doc-strings, why would he only do
that for core?  People won't care if it's a CEDET doc-string, they'd
just say "Teh Emacs people cant spell!1!!". It's no big deal for him
anyway if everything is in one repo. Likewise when Stefan does some
refactoring, like renaming 'defmethod' to 'cl-defmethod'. Doing this for
all files is a matter of seconds, then commit, done. If Gnus, CEDET and
Org are separate, you have to create separate commits for them, with
their own ChangeLogs. I would argue that it is almost always *less* work
for all people involved if things get fixed right away from the right
person, and putting our built-in packages in different repos will make
this more difficult.

> DE> Say the Python developers would decide: Hey, many people like Django, so
> DE> let's just put their latest git master into our release and ship it. Would
> DE> you think that is a good approach?
>
> Some companies have actually done this. I remember when ActivePython bundled
> quite a few things, making it an attractive alternate to installing core
> Python (back when package management was still very poor in Python world).

The question is *how* did they do this. You think they just copied it
over and hoped for the best? Or maybe they did have one repo were
everything was checked in, and where they carefully tested it, maybe
even applied their own patches to Django which they couldn't or wouldn't
get upstream?  I don't know! Since it is non-free, we cannot check,
unfortunately.

-David