Re: [Gnu-arch-users] Mirrors and remote repositories...

[Tom Lord]

    > From: "David A. Wheeler" <address@hidden>

    >> David: I don't think that commits against mirrors should be
    >> _automatically_ redirected. Rather, I'd like to see a mechanism so
    >> that you can separately register the read and write halves of a single
    >> archive name.

    > That sounds very good, it's certainly flexible.
    > To make that reasonable, I think meta-information about that
    > needs to be recorded in the archive so that by default the
    > "right information" is filled in.

Mmmm..... no.

There's plenty 'o pragmatic reasons against that (e.g., ensuring that
all mirrors are updated if an upstream source moves).

There's a deeper political reason that arch leaves archive location
authority management squarely in the hands of each user and nowhere
else.   Getting this stuff automagically from archive meta-data would
transfer that authority from the user to the archive owner.

It's ok to add features to make user-managed archive registration
easier.   Recent examples are the `grab' subcommand and the ability of
register-archive to accept just a location as an argument.  But I
really want to keep a lid on this kind of thing and carefully limit
where it is applied.  `grab' is ok, for example, because it is (in
part) a convenience on top of register-archive.   Invoking `grab'
automatically from `what-changed', picking the location to grab from
out of some log message, would not be so ok -- it would entangle the
convenience feature with the core revision control functionality.

That said, an analogy could be made to internet hostnames and the
progression from /etc/hosts to /etc/resolv.conf and the invention of
DNS.  The DNS model (as deployed, with its unique privileged roots)
isn't quite right for arch -- users should be able to mix and match
their authorities; DNS is already there underneath to provide global
uniqueness when its needed.   But the general idea of auto-propogation
of useful naming databases is fine.

In other words, I can imagine (for example) an extension to jblack's
mirror farm that would turn him into a de facto archive naming
authority -- and a code base implementing that so you could have a
parallel authority of your own.

Think of it this way: anticipate (probably won't happen but the
potential for it is a good M.A.D. scenario) a big fight about naming
authority for archives.  I want to (continue to) enable that fight to
take place and for people to vote with their feet by messing around
with their own configuration of arch.  I want the core revision
control functionality of arch to not take sides or give any advantage
to any side in that fight.  That fight should take place one level up
in the software stack.  (Where, since it can take place there without
actually disrupting the revision control funtionality, hopefully it
won't -- because nobody can win.)

Another way to say it is that just as the source (in free software,
anyway) is a public good --- so too the revision controlled history of
the source.   "Ownership" exists only in the Raymonesque sense of
"everyone" agreeing that, "yeah, so-and-so `owns' that project".

But in the short term -- step _way_ back.  The core functionality
needed is just an extension to the ~/.arch-params/=locations mechanism
so that a given name can have two locations registered -- one for
read-only and the other for read/write.  Further convenience stuff can
follow from that.

(The other expression of the politics -- the reason for making archive
names different from archive locations in the first place (aside from
just administrative convenience) -- is so that even though DNS names
are very much a form of private property, archive names are not so
much so.  (Trademark foo can muck that up, unfortunately -- but the
P2P-ish nature of how archives work undermine even that weakness.).
There's a game-theoretical contest for control over a given archive
name.  I want to keep that game simple and keep the games regarding
how each archive instance on the net is labled as separate as
possible.  Forcibly linking a mirror to some upstream source within an
archive turns the naming game for the mirror and the source into
something more complicated than a simple sum of the two individual
games of the two archive instances.   If you know what I mean. (I'm not
_entirely_ sure I do but this is my story and I'm stickin' to it.))


    > >The next question then is what to do about
    > >auto-updating the mirror during reads.

    > Do you mean when I get from a mirror, automatically checking the
    > mirrored original and if the mirror is obsolete fixing the
    > mirror?
Yes.

    > That sounds like an interesting option, but it seems to me that
    > that might really screw up disconnected operations (where you CAN'T
    > access the original).  Or do you mean something else?

No, that's what I mean and that issue is one reason why it's "the next
question" rather than "you need to do this too if you want me to
merge".

-t