[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] feature plans from over here....
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] feature plans from over here.... |
Date: |
Tue, 17 Aug 2004 11:41:51 -0700 (PDT) |
I'm announcing that I (and my compatriots) intend to somewhat heavily
hack everything in arch that relates to ~/.arch-params.
We plan to:
~ add support for multiple identities
You should be able to have multiple arch user ids.
You should be able to set various parameters (e.g.
your archive registrations) based on which of your
user ids you are using.
~ clean up archive and mirror registration
The little hack of naming archives with "-MIRROR" or
"-SOURCE" is fundamentally lame.
We plan to clean up the database of registered archives
so that you can have one record that lists all the locations
for a given archive and enumerates the mirroring relationships
among them.
Related to that, we'll add some stuff so you can configure
mirroring rules and have the rest be automated: For example,
statically remember that a mirror should be "pulled on demand"
or "pushed after commit". The ~/.arch-params database will
be expanded to allow such policies to be recorded.
~ add archive aliases
Yes, we'll add short-names for archives.
Think how nicely this works out in combination with multiple
identities: we can make the short-names for archives
identity-specific.
So, while I'm wearing my Arch Maintainer hat, the short archive
nickname "mainline" will mean one thing. While I'm wearing my
Pika Maintainer hat, "mainline" will mean something else.
~ transactionalize ~/.arch-params
A special case of using arch would be using arch to maintain
your ~/.arch-params directory.
We plan to build in that special case and add some high-level
commands to make it easy to use.
One interesting idea to consider is what happens if I publish my
~/.arch-params and you want to merge it into your ~/.arch-params.
"Merge", in this case, can have some very specific meanings. You
can merge *far* more intelligently if you know that what you are
merging is a ~/.arch-params than if you try to merge generically.
We plan to add some fancy merging support for ~/.arch-params
settings.
~ allow other directories
Of course, the well known thing we need ---
% tla --params DIR
to use DIR instead of ~/.arch-params
There's more than what I've listed above but that should give the
general flavor.
Objections, ideas, etc.?
This work will, I believe, begin to:
~ build-in to tla the core functionality of a super-mirror
~ simplify the new-user experience when joining a new arch-using
project (just merge in the official ~/.arch-params of the
upstream project)
~ simplify being a "site maintainer" for a large collection
of arch archives (both master and mirror)
-t