gnu-arch-users
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]