Re: Release update

[Yavor Doganov <yavor@gnu.org>]

At Mon, 01 Dec 2008 21:43:01 -0500,
Chong Yidong wrote:
> 
> We are getting pretty close, and currently there are two main things
> to do before starting the pretest: adding ruby-mode to the CVS
> repository, and making rmail-mbox/pmail ready for use.

I don't know what is the Emacs maintainers' opinion about the GNUstep
port wrt release status/goals, but I'd like to mention that in its
current form it is not usable as a replacement of GTK+/Lucid/nox.
Maybe this is not a problem in general, as probably the main goal of
the port is to make Emacs available for users of the Muck OS X system
(as a replacement of the Carbon port).

I don't see it this way, though, although I realize I'm in the
minority.  As a GNUstep user my goal is to use Emacs.app as a
replacement of the Lucid build (or the GTK+ build with the GTK-Step
GTK theme).  This is not possible now, even with my extremely low
Emacs usage requirements.

Whether this is considered release-critical is up to the Emacs
maintainers to decide, naturally.

The trouble is that if GNUstep users don't find this flavor usable to
run it by default, bugs will not be even discovered, let alone fixed.
Of course, it is impossible to fix all bugs in time for the 23
release, but at least the most critical ones should be nailed.

Here is a short summary of what I consider important for the GNUstep
port (in my capacity as a humble user).  I am still experimenting with
some of the bugs to which Adrian sent useful comments.

* #1333: Emacs.app does not load ~/.emacs
  The consequences of this are a real disaster.  Emacs also doesn't
  inherit the environment, which in many cases makes usage of external
  processes a PITA.

* #984: Emacs.app segfaults on startup with the cairo backend
  The cairo backend is still considered experimental in GNUstep Back,
  although probably 90% of the people are using it, because rendering
  is faster and much more beautiful than art.  Not being able to use
  Emacs with cairo means "downgrading" to art, as it is not possible
  to define the backend on a per-app basis (and that's how it should
  be).  This is a GNUstep problem, I think.

* #620: Bootstrapping with the GNUstep port impossible
  Distro unfriendliness.  This is not a problem for regular users, as
  released Emacs already contains byte-compiled files, and there is an
  easy workaround for bootstrapping anyway.  However, nowadays the
  majority of the users prefer distro-provided packages.  Among the
  distros who care about GNUstep and ship it, Emacs.app currently
  cannot be provided for Gentoo because of this, and for Debian
  (gNewSense actually) I am doing a horrible hack/workaround that 
  no sane (Debian) maintainer would upload as an official package.
  As a result, I suspect that at the end this port will have even less
  testing.

* Some GNU Coding Standards violations that I'm going to report soon
  (with patches, eventually).  The problem, basically, is that the
  Emacs.app build system breaks certain user expectations that were in
  place since about forever.

I hope that even intrusive patches for the GNUstep port will be
accepted in the pretest period.