emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gud lord!


From: Stephen J. Turnbull
Subject: Re: Gud lord!
Date: Wed, 11 Jun 2003 22:36:29 +0900
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux)

>>>>> "Robert" == Robert Anderson <address@hidden> writes:

    Robert> One [arch-mode for Emacs] is by Walter Landry and one of
    Robert> them is by Stephen J. Turnbull (who also does Xemacs
    Robert> development and

Landry's arch-mode looks quite complete.  My own mode is not
appropriate, both because it is extremely incomplete, and because it
deliberately enforces a particular discipline of software engineering
that I aspire to, but can't get myself to do as a matter of habit
without a supervisor.  My s.o. refuses to take on that role.  :-)

    Robert> has been talking about the possibility of using arch for
    Robert> Xemacs).

The talk about using arch for XEmacs was before I knew much about
the practical side of arch.  Things are looking much better for the
near future, but I would not want to use the current stable version of
arch on a project as big as an Emacs.  The arch that Emacs would want
to use is just now being developed.  Among other things, there's a new
algorithm being implemented that claims to make the kind of development
that's being done in the repeated cross-pollination of emacs HEAD and
emacs-unicode much easier to track and manage.  But it only has two
users at the moment (literally two, I think).  Tom Lord has suggested
that he doesn't see much in it that existing facilities don't do, but
this hasn't really been proved yet.  I think that puts "paid" to the
notion that arch is "stable" at this point in time.

Also, XEmacs has an important motivation for using arch that Emacs
does not: it would make our package maintainers _much_ happier by
getting rid of the "must be in XEmacs repository" requirement, which
duplicates home-grown repositories in many cases.  This also means
that we may be able to "dip our toes in the water" first, which Emacs
really couldn't.

I think it would be a very good idea for the Emacs community to let
XEmacs take the lead on this one, at least if it's going to happen in
the next 18 months.  After that, there should be some large-project
experience (in terms of MB of code managed, eg, Jonathan Walther's
Xouvert and an XEmacs branch), and maybe some experience with large
projects where the metric is # of developers.

I will likely create an XEmacs arch repository within a month.  If it
works for me, I'll find a way to publish it during the summer so
others can access it.  I'll try to remember to keep notes, so GNU
Emacs can profit from my experience, or (if appropriate), simply cut
your losses at "just five minutes of your time" by ignoring the whole
thing thereafter ;-).

    >> - is arch available on all the platforms used by Emacs
    >> developers and other people trying things out via the anon-CVS
    >> repository ?

    Robert> This is probably the biggest hurdle.  The answer is "very
    Robert> likely not." Especially if non-cygwin windows support is
    Robert> required.  This is why an interim interoperation scenario
    Robert> is almost certainly the way to go.

It doesn't work for me OOTB on Mac OS X, but I haven't tried very
hard.  (I keep suppressing csh in one context after another, and it
keeps popping up in odd places; that may have something to do with
arch on MacOS difficulties since arch really insists on a POSIX sh.)

    Robert> In any case, I think an emacs mode is a very minor point
    Robert> wrt the value of adoption.

Not to Emacs developers.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]