Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.

[Tom Lord]

    > From: Colin Walters <address@hidden>


    > I still don't think that's necessary, but it's a far cry from
    > creating a new ill-specified "configuration language" and
    > embedding it in patch logs and elsewhere, and requiring all new
    > Arch implementations to parse and execute (!) this language.

Which is precisely why I am taking great care to specify the language
rather precisely.   I think I've been good about pointing out in these
posts where the spec is incomplete, what it takes to fix that, and why
the things I'm leaving incomplete at this stage are not a big deal.

If you think I have failed to do those things that's fine but please
be specific:  what concerns you about the spec we have so far?


    > >                 (define maintainers '("joe" "jane" "fred"))

    > >                 (define upstream
    > >                   (if (member my-user-name maintainers)
    > >                       "address@hidden/proj--devo--1.3"
    > >                       "address@hidden/proj--public--1.3"))

    > What problem is this solving?  In what situation does it arise?  First,
    > wouldn't you have the "devo" be in a separate archive not accessible in
    > the same place "public" is?

Why would the archives necessarily be separate?  Perhaps I need to
commit to that other archive for some other project.

What that definition is solving is that it is a definition for
`upstream' that is portable among many users.  One person can write
that definition yet many people can use it.  It captures, in useful
form, part of the policy of a particular project.  



    > >                 (define patch-queue
    > >                   (if (member my-user-name maintainers)
    > >                       "address@hidden"
    > >                       "address@hidden"))

    > I am unconvinced that people are going to be typing "tla submit" often
    > enough that it is necessary to create a new configuration language.  And
    > why in the world do you even need to have different email addresses?  It
    > should be based on the GPG keyid or the like.  That way there is no need
    > for client-side configuration that can become stale.

For one thing: perhaps the rule is a special case in that both email
addresses live at gnu.org.   What if the rule was:


        (define patch-queue
          (if (member my-user-name maintainers)
              "address@hidden"
              "address@hidden"))

(In any event, the configuration from this rule is not exactly
client-side and is certainly not server-side.  It's more like:
maintainer-side.)


    > >   Suppose that I send you (or build into tla, as a default) a=20
    > >   template like:

    > >     (define my-id "<PUT YOUR ID HERE>")
    > >     (define my-default-fq-version "<YOUR-ARCHIVE/YOUR VERSION>")

    > >   and the rest of the program expressed entirely in terms of those:

    > >         (define my-default-archive (archive-of my-default-fq-version))
    > >         (define my-default-category (category-of ...))

    > Wouldn't that all just be built in as sane defaults?

In general, no.  Because the defaults that make sense for me as a home
user aren't the same as the defaults that make sense at the office,
etc.  

-t