Re: Merging multitty

[David Kastrup]

Richard Stallman <address@hidden> writes:

[ Károly wrote: ]

>     Fixing multi-tty on Windows and other platforms does not really
>     need any platform API experience: it's mostly a matter of
>     understanding C compiler error messages and changing references
>     to previously global C variables to their new terminal-local
>     places (accessible via a frame handle).  If the code compiles
>     successfully, it will likely work.
>
> Let's install this code in a branch in the Emacs repository
> immediately.

Agreed.  Károly, can you arrange with Miles to figure what it takes to
do this via his arch mirror (sounds like "archbishop" actually)?

> That way, other people with write access to our repository can work
> on making it compile on other systems.
>
>     Yes.  If you guys decide to merge the Unicode branch first, I'll
>     simply devote a weekend to resolve merge conflicts and continue
>     syncing with the trunk as long as necessary.
>
> In that case, I agree we may as well merge the unicode-2 branch first.
>
> Thank you for your continued help.

Ok, here is the beef.  We currently have the the following main
active construction sites:

EMACS_22_BASE
trunk
unicode-2
multi-tty

We have a certain lack of resources.  We currently have several
externally maintained packages in kept-back versions in our trunk in
order to cater for the release.  We have a bunch of hardly-maintained
packages in Emacs CVS.

We presumably want to minimize our workload and minimize bitrot.  We
want to maximize developer motivation and output.

We have by now pretty much fleshed out what Emacs 22.1 will look like
(basically, nothing NEWS-worthy will happen anymore).  What with Emacs
22.2 and what with the rest of the EMACS_22_BASE lifeline after 22.1
is tagged and released?

The core work for Emacs 23.1 is fleshed out already.  I strongly
suggest that we focus all attention on Emacs 23 after the release.
That means that Emacs 22 releases will just contain bugfixes, but no
package updates (unless that is absolutely the cheapest way to fix a
bug).  If there is sufficient interest for a different model, we can
appoint a _separate_ maintainer for Emacs 22 who will have the task of
integrating updates at his discretion while not destabilizing Emacs 22
in the course (separate stable branch managers are actually not
uncommon in software development).

But for the main developer taskforce (all the millions of them), Emacs
22 compatibility should not remain important.  There should be no
energy spent on keeping material in trunk compatible with Emacs 22.

For Emacs 23.x, we might adopt a different strategy if there is no
clearcut plan for Emacs 24 with a more or less clear timeline (I would
expect that the next serious architectural changes could be
bidirectional support in the display engine, and possibly some Lisp
engine changes, like quadrupling the size of Lisp integers).

But 22.x sounds like a good candidate line for a permanent feature
freeze.

If we do that, EMACS_22_BASE is mostly off the chart for continued
work.  So we have just three areas of construction remaining.

Merging unicode-2 will get us rid of another construction area.
Károly has basically agreed to take upon himself the work of keeping
multi-tty in line, so while he is able to keep up with this, we are
down to a single area of development soon.

The main question I currently see is about _when_ to open the trunk
for frozen changes: package updates and code changes that were kept
out of Emacs 22.1 because of the release process.  This is the step
that will get developers again the motivation to _improve_ Emacs all
across the board.  I don't think there is sense in opening the trunk
before merging emacs-unicode-2: code contributions should work right
away with emacs-unicode-2, and emacs-unicode-2 is quite invasive, more
so than multitty (though things like tramp would likely interreact
with both).

So I'd propose to do the following _now_: move multi-tty into a branch
of Emacs CVS.  It is likely that the branch synchronization can then
not only done by Károly (by the way, is that the polite way of
addressing you?  It is hard to figure out for me what part of a
Hungarian name one is supposd to use) but possibly Miles will also
have a handle on this where the arch thing is concerned.  We want to
merge multi-tty as soon as reasonable in order to avoid duplicate
work.

Merge unicode-2 now.  If we can agree that all of 22.x is going to be
released from the EMACS_22_BASE branch and that only bug fixes should
make it there, it does not actually matter whether Emacs 22.1 will be
tagged and released today or in two months: either way, essential bug
fixes will have to be applied to EMACS_22_BASE as well as trunk.

So this would likely end the freeze frustration and put the 22.1
release pressure out of the immediate limelight.

So _after_ the merge of unicode-2, I'd consider a lift of the trunk
freeze for general improvements reasonable.  This will be a temporary
burden for the multi-tty workers, but will take time pressure for the
"stable goal" off them.  And it looks like the architectural
specialties of multi-tty are well-confined enough so that merges will
usually be straightforward.

When are the unicode-2 people ready to merge, and would everybody else
be ok with this plan?  I understand that unicode-2 is working well and
already in active use under several but not all platforms, so it will
mean that some platforms will be cut off from Emacs variants with
updated packages (which would happen in a unicode-2 trunk, but not in
EMACS_22_BASE) for a while, as those would happen only in unicode-2
infested branches.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum