[Gnu-arch-users] empty commits, wrappers, and version control frawemork

[David Allouche]

(I replied to Blackwell because that was the most interesting message on
this thread in a while)

Yesterday, we had an animated discussion on #arch after abentley
suggested we talk about empty commits. That was an occasion for me to
express a position which has slowly been maturing in my mind over
several weeks.

First a handful of facts which I believe are _not_ controversial:

    CLI stability is important, because scripts rely on it, and scripts
    are useful to make people's life simpler with arch.

    CLI changes are important, because the very great majority of users
    are using the tla command line as the only standard interface to
    tla.

    The CLI is getting insanely complicated because scripts and the
    vocation of tla as a low-level tool make it necessary to keep
    a bunch of commands which are essentially useless to users (like the
    make-* commands, compared to archive-setup).

    Many controversial CLI changes would make sense, at least as global
    options, in a user-oriented tool, but are not acceptable in a
    script-oriented tool.

    The librarification of tla is not getting any work, and although
    there is some work going on front-ends, wrappers, and such, they
    tend to have little traction.

    Pressure is slowly starting to build up for features which would
    cause incompatible changes to the archive format. Nothing really
    serious yet, but it is time to start thinking about what tla2 will
    look like.

Then, my _more controversial_ conclusions:

    This discussion about "empty commits" is beating the wrong horse.
    There should be a front-end (maybe aba) user option, to prevent
    empty commits by default, but that is not a good thing to do for a
    script-oriented tool.

    tla is currently trying to meet the contradicting goals of providing
    a stable, mature, reliable low-level tool, and a flexible, evolving,
    customizable end user tool.

    Currently, a lot of convenience features need to be built into tla
    because there is no way to implement them with decent perfomance on
    top of the stateless CLI. For example, "tla replay" is getting a
    heck lot of options and understanding how they relate and interact
    is getting tricky.

    The wrappers/front-ends are limited because they can only use the
    CLI interface, and that makes them very wasteful. Something closer
    to what they need, and not quite painful as implementing libtla.so,
    would be "shell bindings to libtla". That might be implemented as a
    butt-simple REPL, usable as a coprocess, which gives access to the
    libtla features, and would allow reusing pfs connections and other
    expensive resources. It seems that Christion Thäther has something
    like that in mind.

    It's getting time to start saying "no" to new convenience features
    into tla and push people towards aba, raw (the python shell from Rob
    Weir, soon to be released) and mala (the macro language from
    Christian Thäther, still "almost vapor" according to the author).
    
    That's an executive management issue: unless Tom takes a clear
    position in that direction, pressure to make tla more and more
    bloated and complicated is going to increase with the popularity of
    Arch.

    Eventually, probably for tla2, the CLI should be drastically cut
    down and limited to a low-level toolbox for use with scripts. When
    that happens, the end-user tools will have be already mature, so
    something has to be done long before to stimulate their development.

In a nutshell:

    Front-ends suck because they cannot reuse expensive resources
    created internally within tla, and unless that's fixed, the only way
    to do complex things with acceptable performance is to add cruft to
    tla.

    Tla is trying to be the "low-level version control framework" and
    the "standard version control CLI" at the same time. These
    objectives have conflicting constraints, and unless the direction is
    changed it is doomed not to be very good at either.

Cheers, have a nice sunday.

-- 
                                                            -- ddaa