Re: org-export raises stringp nil error

[Eli Zaretskii <eliz@gnu.org>]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Fri, 08 Mar 2013 21:09:36 +0100
> 
> Eli Zaretskii writes:
> >> In any case, doing the built-in packages this way (or something similar)
> >> takes a lot of unecessary churn and merges out of the release process
> >> and I would think that would be a clear advantage to everyone involved.
> >
> > I see that we have come a full circle, what with all this new blood
> > pouring into Emacs development, and we are finally ready to repeat the
> > failed experiment with dividing Emacs into "core" and "all the rest".
> 
> Please enlighten me as to what this experiment was and when it happened
> so I can read up on it.  This is a sincere request, I have no desire to
> repeat a past mistake.

I meant XEmacs.  I'll ask Stephen to describe that and suggest any
conclusions from that experience, including those which contradict my
personal conclusions.

> Note that I haven't said anything about what is core and what is not,
> that issue is orthogonal to how Emacs' structures its software
> repositories.  Off the cuff I'd say we'd end up with roughly the same
> set of "core" packages than today, then grow from there.

I don't understand what that means.  There's no "core" packages today,
the entire Emacs repository is handled as one monolith piece of
software.  The fact that some parts of it are copies of upstream
repositories maintained by others elsewhere is not relevant to the
issues I have with separating them from Emacs.

> What I am talking about is reducing the interdependencies between
> projects on wildly different release schedules for the purpose of making
> the integration easier.  That requires effort on both sides, but I posit
> that there is a net gain — if there is agreement on how to do this and
> an easily followed set of rules that describes the procedures.

Your optimism in this matter is enviable, but my gray hair doesn't let
me share it.  I don't believe in any net gain here.  I don't know why
is that so, perhaps because complexity tends to disrupt any hope of
reaching an "agreement on how to do this" and having "an easily
followed set of rules that describes the procedures".  Heck, we
couldn't even agree on the VCS to use, remember?

> > Good luck (you will need it)!
> 
> This is engineering, not gaming (although I wouldn't mind a bit of luck
> once in a while).

If you don't believe in luck in software engineering, just stick
around for a while.