Re: [Gnu-arch-users] Canonical wrapper?

[Stephen J. Turnbull]

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

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

    Jani> Many arch users are their own SCM guy.Single person
    Jani> projects, playing around with tla, that kind of thing.

So?  Are they going to be happy if they get saddled with a wrapper
that doesn't fit them very well now and gets deprecated 6 months
later?  Of course not.  What they really need is something that is
getting tested on a daily basis by lots of users with varying kinds of
needs.  The way to build toward that is for people supporting such
users to support them, and advocate their solutions here, on IRC, and
on the wiki.  That's not happening yet, not even for aba and xtla.

So anointing a candidate now will just lead to the Emacs people using
something based on Emacs, and others using aba, and others depending on
bash or zsh completion and scripts, and about half of the experienced
users doing none of the above, because they're happy with their
homebrew wrappers, and nothing will change much, except that newbies
will use the "official" wrapper until they realize that none of the
old-timers are using it and it's not keeping up with the development
in the rest of Arch.

It could happen differently, of course, but why Tom & the Lieutenants
should bet on it happening differently I can't see.

    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.

    Jani> There are not so many and keeping them out of tree makes new
    Jani> ones appear.  Choice sucks in this case too because it makes
    Jani> you try out all the possibilities to decide which is
    Jani> best.

Hey, guess what?  _You haven't mentioned your favorite yet._  If you
don't have strong enough feelings about which one you want to mention
it in a thread on the subject of choosing a wrapper that you've posted
to several times, what makes you think anybody does, or that we can
get agreement?

    Jani> The current approaches are not so radically different
    Jani> IMHO so as to say competition is good because it leads to
    Jani> exploring various novel ways in wrapping tla in a scripting
    Jani> language.

I disagree.  An approach that requires installing and using Emacs
(IIRC, xtla) _is_ radically different from a standalone UI like aba.

    Jani> It seems to me that you and other arch veterans are trying
    Jani> to inflict upon all new arch users the pains you had to take
    Jani> while using the first versions which I assume had an even
    Jani> less friendly UI :) And it seems to me you're forgetting
    Jani> that people who would use arch are not all long time unix
    Jani> masters with an exaggerated fondness for pipes and DYO
    Jani> stuff.

Rather, it seems that people who want a _very_ complex feature which
has no clear specification and no broadly acceptable reference
implementation are trying get it without doing the work themselves.
Just by jawbone: accusing the people who have done all the work to
date (plus a few less-than-innocent bystanders like me) of behaving
sadistically toward new users.

Even just smoothing out a few of the rough edges is more complex than
you guys seem to think.  And nobody has said anything about not taking
care of new users, just that they're not fond of the idea of putting
in the effort necessary for dramatically streamlining the tla UI
_right now_.  It's a lot of effort, and it's not clear it won't be
99% wasted if it's done by people who don't need it themselves.

On the other hand, none of it will be wasted if it's done by "SCM
guys" who need it to support their projects' processes _now_, not to
mention that they'll probably do a substantially better job, too.  I
think that's the way to go.

It would not be hard to change my mind (NB, that doesn't matter at
all, and I don't know how that corresponds to changing Tom's) about
the acceptability of anointing a more-or-less official wrapper set in
the interim.  Just do the work necessary to specify the new UI
("simple and user-friendly" is _not_ a specification, nor is "it's
stupid that undo requires a pipeline").  Or get a core of people to
coalesce around one of the wrapper sets and develop that into a spec
and advocate it.

But I don't see either happening at the moment; what I see is people
pretending that "the way things are now sucks" is a spec for "a way to
arrange the future that doesn't suck."

It ain't.

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