Re: New maintainer

[David Kastrup]

"John Wiegley" <address@hidden> writes:

>>>>>> Phillip Lord <address@hidden> writes:
>
>> I mention this not to stir up old arguments, but simply to point out that
>> these arguments have not been resolved in the past. While I am hopeful that
>> they will be resolved in the future, I suspect that trying to sort this
>> issue out now is a side-track, which should not block discussion of the
>> maintainership.
>
> I realize we're on the 1000th round of this discussion, but I've not been
> directly involved in it before, and it has a direct bearing on my willingness
> to maintain Emacs.
>
> Guiding a project's technical future requires devotion and enthusiasm, and a
> certain degree of freedom. If the directions I want to take Emacs in are going
> to be consistently hampered by the "needs of freedom", this will cause me to
> lose all such energy.
>
> I'm going be the one at conferences, talking to users, saying, "Yes, we know;
> yes, it's a great idea; yes, it should be there; yes, I even want to do it
> myself, yesterday; but talk to me in ten years when GCC has gotten around to
> providing what we need."

No, that will not be the case.  "when GCC has gotten around to providing
what we need" suggests that GCC is holding things up.  They are equally
"stomping at the bits", meaning that there have been previous attempts
of writing out the annotated syntax tree or similarly generally useful
stuff that could feed other functionality based on GCC but not falling
under the GPL with regard to "the whole work" criterion because of using
a generic interface.

So for developing this kind of functionality in lockstep with GCC
developers using specialized (namely non-generic) interfaces, you'll
likely find a path leading forward.  The more generally useful such
interfaces will get, the more it will require seeking for an adaption of
FSF policies to the realities you are eager to create.

You won't be turning this ship on a dime.  But I also don't think that
it wouldn't budge when you try getting the pieces in place.  But the
pieces would have to start with working with GCC developers and Richard
open-ended on the kind of needed functionality rather than being based
off Clang's existing state.

> I'm beginning to think GNU Emacs will need someone who also cares
> about the freedom argument first, and the technical needs second,
> because I'm very much concerned I would chomping at the bit to move
> forward, and unable to for reasons I don't necessarily agree with.

As I said: I don't think you'll be unable to move forward but you'll
need to coordinate that movement with the other horses in the equipage
(sorry, your analogy).

-- 
David Kastrup