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

[James Blackwell]

Hello everyone,

This is long, but I figure its worth reading. Feel free to demand a
refund if it doesn't entertain you.

Over the last few weeks there's been quite a bit of discussion about
furth and xl. Conversations have ranged from "do we need something this
complex?" all the way to "Scheme/Lisp sucks!" I've certainly been a
participant in these discussions, typically on the negative side.

One of the first concerns is that building a language into arch for
configuration files is that it's a serious case of overengineering. The
argument goes something along the lines of 'Furth is too much, will take
too long, will impede other development'. This is a reasonable worry to
have; after all, who wants something like the libneon buffer overflow
problem to sit around for X number of more months, while furth is being
developed? 

The first issue that I'll tackle is the over-engineering part. We all
agree that arch is a growing project, and we'd probably all agree 
that arch is going to continue growing. As arch grows, we're going to
need to store more and more configuration data as time passes. The
problem, as we have it, is that storing this configuration info is going
to nickle and dime us to death over time. For each given configuration
item, you're looking at at locating a file (generally a few commands),
opening the file properly ( a couple more), actually getting data,
closing the file, and so on. Any given time that we do this, its
reasonably easy to do so, and the code is generally clear. However, we
keep replicating the same 10 steps again, and again, and again. That's
nonsense. By building a configuration library like furth, we can do it
just once, and be done with it. Imagine how much easier the coding would
be if we could make a call along the lines of (and I'm just making this
up out of the blue. I'm sure Tom has different plan in mind)

    ...
    if (getconfig("greedy-library"))
       do greedy library stuff
    else
       do the other stuff

Sure, we can put this work off for a while. Do it next month or next
year, or sometime in 2020. But we can pretty easily tell that we'll have
to do it *eventually*. Since we've detected a need to have a
configuration library of some sort, we can easily surmise that the
sooner we implement it, the less code that we'll have to replace when it
*is* used. 

However, there's another issue related to this. There's some other
things that would be really useful to use in arch. Patch queue managers,
automatic submissions, bug tracking integration -- really about a
million other things. The perfectly suitable interface to all of these
things is some sort of embedded language. Then, you can do all sorts of
things like figuring out users and groups for the pqm... figure out who
the developer is... set up notifications.. the possibilities are
actually endless because its a whole language.

That's a lot of stuff to tack onto a revision control system, right?
Well, this is how we win the game. We make it so easy for a project to
handle every aspect of revision control (there's a lot more than just
merging cleanly), that o use anything else would be idioic. Already,
some of our compeitors, like darcs and bitkeeper, already have some of
these things in place. 

But all the same, if you're like me (you probably are), you're worried
on two points. One worry is that even if you're interested in just arch,
you're going to be stuck having to learn scheme and deal with all of the
intricacies of a language that seems hell-bent on doing everything
backwards. You don't have to worry about this. I talked with Tom on this
very issue, and he promises that as far as it concerns arch-the-program,
the scheme stuff will be kept light. You're not going to have to learn
how to write functions in scheme, you're not going to have to figure out
flow control, none of that. About the worst that you'll bump into will
look something like (but not exactly like) this: 

    (define mirror-locations ( '("http://siteone.com";
                                 "http://sitetwo.com";
                                 "http://sitethree.com";)))

When it comes to arch configuration, it shouldn't get any worse than
that (Tom promised). Now, some of you may still be saying "But I don't
want to do even that much". That's absolutely fine. There's still the
front-end interface ( the hypothetical "tla add-mirror" command) for the
nondevelopers. For the developers, I think its going to be hidden behind
an interface as well, so you'd just do something like

    rel_table mirror-locations = getconfiguration("mirrorlocations");

Now, sure, the interface may not be exactly like that (it may be
diferent, not quite that simple, may have extra parameters, etc), but I
think that's the _sort_ of thing that Tom has in mind. By piggybacking
the pqm/other stuff, the arch program gets configuration "for free".

However, this still leaves the other half of the over-engineering
argument. While Tom is off coding furth and xl, then who's merging
patches, doing releases, and performing the long list of other 
responsibilities that the project lead is normally supposed to do. In
order to help addres this exact issue, I have created
address@hidden/tla--devo--1.3, and into that branch I have
started merging changesets from a variety of sources. Then, on or about
31 July, I intend to release arch-1.2.1rc1.tar.gz and, as needed, 
release successive release candidates (though not many). If, after a
week it looks like the rc is right, then I'll inform Tom that there is
an imminent release of arch. I'll then sit back for about a week to give
Tom the ability to review the rc at his leisure. If he wishes, he 
can bless the release candidate in its entirety, and its given to the
world. However, if there's something in the rc he doesn't like, he 
has the priviledge of vetoing any changeset that I've approved. If this
he chooses to veto a changeset, I might either agree or disagree. If I
agree, the changeset is gone. If I disagree, we (as in the community)
will discuss the merits of the changeset, with a strong propensity
towards dropping the it.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400