Re: MAINTAINERS file

[Thomas Lord]

Stefan Monnier wrote:
> To the extend that (like Arch) Bzr can use just `sftp' to read&write
> a remote repository, I guess that there's no need for anything special,
> other than a location.  Using a subdir of
> arch.sv.gnu.org:/archives/emacs will work, but it's ugly.
>   


Just to brag:  Arch's "dumb archive" architecture let's an archive
be hosted by sftp or ftp:  no arch-specific program has to be installed
and operated on the server side -- only some commonly available,
file-system-style service.

Relying on only "dumb servers" was a design constraint from the
earliest days of Arch.   The constraint was deliberately adopted to
achieve a goal:  to make it easier for people to "deploy" arch without
requiring cooperation from a third party.   For example,  that sftp is
already an option on a host makes it easier to deploy arch on that host,
without any change needed from the host operator.

It's nice to see that pay off *internally* to the GNU project but that's a
happy accident.   The original thought was more banal:  it's easier and
cheaper for people to find themselves an FTP or SFTP host than it is
for them to provision a personal host on which to install and operate
a version control system server.   I was thinking of "basement hackers"
who could maybe get a gratis FTP site, but couldn't get a gratis place
to install a revision control server that they themselves controlled.  Or,
at least, an (S)FTP site would be cheaper for a basement hacker.   I also
worried about the so-called "dissident" problem: piggy-backing on "dumb 
services"
makes it easier for people to publish source code even in circumstances
where permission would seek to require yet not offer itself.

The original thought was that centralized project sites like Savannah
and Sourceforge might fade away (or, rather, morph into more
"Freshmeat"-style services).   That's part of the reason I'm so
flummoxed by "Launchpad," which seems a complete inversion of the
original aims of Arch.

-t