[Gnu-arch-users] Canonical wrapper? [was: Online book for usability]

[Stephen J. Turnbull]

>>>>> "Jani" == Jani Monoses <address@hidden> writes:

    >> The reason that reverting changes to 'a' single file(s) yet is
    >> that _you_ haven't provided the code to do it -- yet. There's a
    >> lot of things that a lot of people want, and by definition, its
    >> not going to get done until its done!

    Jani> Not necessarily IMHO.  From what I see some functionality
    Jani> will never make into tla core because it is easy to do by
    Jani> scripting around what tla already provides. The problem is
    Jani> not that a 'silly pipe' has to be constructed or even a few
    Jani> lines of bash to get something done, but the fact that this
    Jani> has to be done many times by new users who are overwhelmed
    Jani> by tla and try to (ironically) keep complexity and stuff to
    Jani> remember down by not installing aba, tla-cvs-tools, pyarch
    Jani> etc.

I don't get this argument, especially combined with the "network
externalities" argument (that projects must settle on a single SCM
because everybody needs to be on the same wavelength).  It seems to me
that a project needs to have an "SCM guy", and that guy can choose, and
help to maintain, the wrapper that he judges most compatible with his
project.  If "new users", ie, the rank and file of the project whose
leaders have just decreed that Arch Shall Be The Only Righteous Way To
Contribute, are reinventing the hamdriver, then the first thing you
should check is whether the leadership's thumb isn't clogging a vital
sphincter.

In other words, jblackwell is right when he says "the feature ain't
there because you didn't contribute it."  It's just that you might not
be contributing directly to tla, but rather to one of the wrappers.

    Jani> It would all be simpler for newcomers to have such a
    Jani> wrapper-set bundled with tla.

But which one?  In the current state of affairs, as soon as you get
one in, all the others may as well come in, I guess they can share a
contrib directory.  They all have their strong points and weak points.

Tom seems unlikely to be willing to pronounce any of the current ones
as "official", since I'm sure he has Pika Scheme in mind as a strong
candidate for the engine of the as-yet-hypothetical itla, which would
immediately obsolete all but the most well-developed of the current
wrapper sets, including many of the shell completion packages.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.