Re: MAINTAINERS file

[Thomas Lord]

Juanma Barranquero wrote:
> IIUC, you're saying "no" to "would we like GNU packages to do that?"
> (ie, using Bazaar). I'm agnostic; I'm just not comfortable with the
> idea of not taking into account reliability, user interface,
> scalability, performance, etc., and blindly assuming that all current
> dVCS are more-or-less equivalent. git is quite fast; mercurial has a
> nice interface, etc. Using one or another does definitely not offer
> the same experience, even if the functionality is very similar.
>   


Probably so but any group of smart people could easily spend
a year arguing about it.   Not even a year arguing about which system
is best but a year arguing just about what "best" means in this context.

Over-optimizing a choice like that can be a *huge* resource
suck and projects and groups fail all the time because of falling
into such traps.

RMS' "style" of running GNU, at least as I've seen it over many
years, is to try to avoid getting hung up that way.   Instead:  just
pick (or build) a list of free software programs that, at least if you
just look at their one-line summaries, should add up to a Complete
GNU System.    Now you are mostly "done".   The next step is
to observe this funky heap of programs and ask "Why does this collection
fail to function well as a complete system?" and then fix those
problems.   Then you're done. 

So, if it seems arbitrary that RMS dubs program X a GNU program
and then says "the Emacs project should use X" well, it probably
is arbitrary -- but the arbitrariness is part of a larger, pretty sane
strategy.   X made the list.   Hope that it's "good enough" to polish
into a component of the complete system.   Worst case is to eventually
back-track and pick an alternative X'.   (GCC, for example, started
out just that way.   So did the current Emacs.    GCC started from
a compiler written in pascal that turned out to not be "good enough"
and Emacs from another Emacs that didn't have a true lisp in it.
Bad choices of X happen but, they tend to get ironed out well so
when it comes time to pick an X, there's no great reason to spend
too much time deliberating over it.


-t

(Maybe, though, it is about time for a new task list and "vision
sketch" of a complete GNU.   For example, an effort could be made
to assemble a candidate FSF/GNU distribution with the expectation
that the effort will fail, but will yield a list of what work remains to
be done.)