Re: [Gnu-arch-users] feature plans from over here....

[Tom Lord]

    > From: David Allouche <address@hidden>

    > General question, who the "we" you are using in your whole email is
    > referring to?

Who me?  I'm a little slippery on my use of "we", sometimes meaning
"the arch community as a whole" and sometimes meaning (in this
context) "some people with whom I'm working off-list on arch
features".   Hopefully context makes it clear what I mean.

    > Role-based set up is a good idea, but I believe that most (or all) of
    > the use cases can be better addressed using context sensitivity.

    > The role-switching model makes it necessary to explicitely switch
    > roles when switch projects. It does not address the "commit with id IX
    > on archive AX and id IY on archive AY" that the proposed per-archive
    > user-id patch addresses.

Similarly to the way that "default archive", once just something you
set in ~/.arch-params, is nowadays (from _some_ commands) something
that can be inferred from the project tree of the current directory.

In other words, yes, you're right --- but the functionality you are
looking for is something to build on top of what we are laying down as
foundation right now.

(Your use scenario and analysis of the "oops" factor are good.... but 
nobody is disagreeing with that.)


    > == Per-role/context archive registrations ==

    > I believe that per-role archive registration is the wrong solution to
    > a number of assorted use cases. As far I can tell, it's only purpose
    > is to shorten the output of "tla archives", however I think that most
    > of the time you should not have to use that command in the first
    > place.

That's not quite it's only purpose.

Here is one example of another purpose:

Suppose that my mirror updating is fully automated.   Certain mirrors
are pushed-on-commit, others are pull-on-demand, and others are based
on cron jobs.  When I add a new archive it's automatically injected
into that automation.

Role-specific archive registration management let's me, in effect,
reference count those archives that I'm managing.  E.g., I need
linux's archive while I hack the kernel -- plus 5 other archives
(e.g. cox's, Novell's, etc.).  I register it under my "linux-kernel"
hat.  As a result, my mirror of linux's archive is registered and
regularly updated.

Now, a year later, I'm not going to work on the kernel.  At this
point, I can just say "remove my linux-kernel hat" and all of those 
archives will be (unless I need them for some other hat) unregistered
and the mirror updates will be cancelled.   All in one nice step.
I'll be my own little (generalized) super-mirror, in effect.

In other words: per-hat archive registrations do more than shorten the
output of "tla archives".   They also establish a nice administrative
framework for grouping registrations into categories and managing them
en masse.


    > Finally, _literal_ per-role archive registrations are ugly because
    > archives are global objects. An archive can only be registered under
    > one name (modulo mirrors), and it is a global name.

Part of the deal with these features is that we will be getting rid of
the name weirdness for mirrors.  All locations for a given archive
will be registered under a single name, the official name of that
archive usually.   Arch will just "know" to use the mirror location
for one purpose, the master location for another purpose, etc.

Archives *are* global objects, but they have context-specific meaning.

At any point in time, for the past 3 years or so, there has been one
archive which is "the arch mainline" archive.   Which archive that is
has changed over time.   A per-hat archive alias, "arch-mainline", is
a useful model for that phenomenon.

    > > >     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.

    > That needs more discussion to get right. 

Discussion and experimentation, yes.


    > One requirement that pops immediately into my mind is the
    > ability to switch between online and offline modes.

Excellent idea.

    > > >   ~ allow other directories
    > > >
    > > >     Of course, the well known thing we need ---
    > > >
    > > >       % tla --params DIR
    > > >
    > > >     to use DIR instead of ~/.arch-params

    > Actually, once you get around the initial repulsion, hacking $HOME is
    > quite simple, effective and unavoidable to some extent. For example, I
    > will not make the pyarch test suite rely on the correct handling of
    > --params. We have recentley seen a regression in the support of
    > "update --dir" so a regression in --params does not seem impossible).


The problem is that tweaking $HOME effects other subsystems as well.
E.g., is it really certain that you want all of your hook scripts
invoked by tla to use the altered $HOME?   


    > Also, having to add an explicit option for using another params
    > directory might be a bit heavyweight for some people. 

Perhaps but that's an isolatable subproblem.   I.e., if the extra
option proves to, in fact, be too heavyweight -- it's pretty easy 
to build alternatives once the extra option support is in place.

    > I suggest the
    > params directory be specified, by order of priority, by:
    > 
    >   1. --params option (absolute path)
    > 
    >   2. ARCH_PARAMS environment variable (absolute path)
    > 
    >   3. $HOME/.arch-params
    > 
    > Since that feature is only useful for scripts and wrappers, always
    > requiring absolute paths should not be a burden (just use a variable
    > here) and will significantly reduce the oops factor.

Perhaps.  

Your (2) is very problematic.   Should tla unset ARCH_PARAMS before
calling `exec()'?   Should it *set* ARCH_PARAMS?   Should hook scripts
do either of these?   What happens with an "unintended recursive arch
invocation?"   If you had the envrionment variable hack, to use it
accurately, you're going to be using it as if it were an explicitly
passed parameter (rather than an environment variable).   There are 
uses for dynamic scope but this is a situation where I see it as just 
confusing and error-prone.  `--params' is more tedious but more
precise and just about equally expressive.

(And, anyway, "hats" should *mostly* eliminate the need for a "--params"
option.)

-t