Merging multitty

[Karoly Lorentey]

I will put effort into getting it working again on Windows (assuming
noone else beats me to it), whether it is on a CVS branch or the trunk,
as I have done with emacs-unicode-2, but due to the time I have
available this could take a couple of months or more. I don't think it
is acceptable to have the trunk broken for that long, as it will
prevent some other developers who use Windows from helping with
Emacs 23 development, if they do not have the w32 api experience to
help with fixing the multitty breakage, for example they may want to
help with some Lisp package.

I agree that it would be nicer if multi-tty branch would compile on
non-GNU platforms before merging.

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.

I have my doubts that if we merge unicode-2 first and postpone
multitty until all issues with it are resolved, the issues will never
actually get resolved. In particular when multitty is not kept
synched to the trunk after a unicode-2 merge.

Why would you not sync multitty to the trunk after the unicode-2 merge?
Surely Karoly, Handa and anyone else willing and interested should start
on resolving the merge problems as soon as possible.

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.

I agree that it won't happen in Karoly's private repository. I have
tried using it, but the revision control system he uses seems to be
unstable (from a user interface perspective), and the instructions he
gives for checking out no longer work. Reading the the latest quickstart
guide for bazaar did not really help. But committing it to a branch ASAP
would let the work commence on stabilizing it on other platforms ready
for merging into trunk.

The inconvenience and unavailability of Arch/Bazaar on non-GNU platforms
is an excellent point. We must create a bidirectionally synced branch
for multi-tty in Emacs CVS immediately.

I disagree with that assessment. It presumes that not making Emacs
multitty-capable ever is a reasonable option.

It is the only option if we don't have anyone willing to maintain that
capability. But judging from your activism on this, I don't expect we
will have that problem.

I can definitely help maintaining the multi-tty feature set, if you
don't mind occasional delays. A factor to consider: most if not all
multi-tty bugs I have seen so far were multi-tty specific and did not
occur with single-terminal usage. When multi-tty fails, it fails
gracefully and does not affect single-terminal users and developers.

[Károly Lo"rentey]

I will put effort into getting it working again on Windows (assuming
noone else beats me to it), whether it is on a CVS branch or the trunk,
as I have done with emacs-unicode-2, but due to the time I have
available this could take a couple of months or more. I don't think it
is acceptable to have the trunk broken for that long, as it will
prevent some other developers who use Windows from helping with
Emacs 23 development, if they do not have the w32 api experience to
help with fixing the multitty breakage, for example they may want to
help with some Lisp package.

I agree that it would be nicer if multi-tty branch would compile on
non-GNU platforms before merging.

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.

I have my doubts that if we merge unicode-2 first and postpone
multitty until all issues with it are resolved, the issues will never
actually get resolved. In particular when multitty is not kept
synched to the trunk after a unicode-2 merge.

Why would you not sync multitty to the trunk after the unicode-2 merge?
Surely Karoly, Handa and anyone else willing and interested should start
on resolving the merge problems as soon as possible.

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.

I agree that it won't happen in Karoly's private repository. I have
tried using it, but the revision control system he uses seems to be
unstable (from a user interface perspective), and the instructions he
gives for checking out no longer work. Reading the the latest quickstart
guide for bazaar did not really help. But committing it to a branch ASAP
would let the work commence on stabilizing it on other platforms ready
for merging into trunk.

The inconvenience and unavailability of Arch/Bazaar on non-GNU platforms
is an excellent point. We must create a bidirectionally synced branch
for multi-tty in Emacs CVS immediately.

I disagree with that assessment. It presumes that not making Emacs
multitty-capable ever is a reasonable option.

It is the only option if we don't have anyone willing to maintain that
capability. But judging from your activism on this, I don't expect we
will have that problem.

I can definitely help maintaining the multi-tty feature set, if you
don't mind occasional delays. A factor to consider: most if not all
multi-tty bugs I have seen so far were multi-tty specific and did not
occur with single-terminal usage. When multi-tty fails, it fails
gracefully and does not affect single-terminal users and developers.

[Richard Stallman]

Your point that Karoly is not going to be available for much longer is a
point against merging into trunk quickly IMHO. Either someone else will
step forward to maintain that code, in which case it doesn't matter if
the merge to trunk happens later, or noone wants to maintain the
multitty code, in which case merging into trunk would be a mistake.

If the code is working, well commented, and clear, then once it is
merged in, people will learn to maintain it. So I agree with those
that think it is better to merge multi-tty first -- if it is working,
well commented, and clear.

If there are some cases it does not handle yet, that is no great problem
as long as it doesn't totally break those cases, and as long as the gaps
are well documented.

[Richard Stallman]

It might be better to merge into the arch version of the trunk, and then
let that be committed to CVS. The multi-tty is already in arch, so
merging back into the arch-trunk should be basically trivial, and using
the regular arch->CVS gateway is probably safer than doing a one-off.

What does arch->CVS give in the way of CVS log entries?
I hope it does not put the entire change log into each file's CVS log!

[Miles Bader]

Post by Richard Stallman
What does arch->CVS give in the way of CVS log entries?
I hope it does not put the entire change log into each file's CVS log!

I would use something simple like "Merge multi-tty branch"
(i.e., exactly what someone merging using CVS would use).

-Miles

[David Kastrup]

So people can use the trunk for changes meant for Emacs 23.

Does it mean that it is ok to merge emacs-unicode-2 into the
trunk now?

Well, this is one of the points we definitely agreed to do for Emacs
23, so it _would_ appear to be in concord with Richard's statement
here.

However, I think we more or less agreed that it would be more prudent
to merge the multitty stuff first and follow up with the Unicode
branch, since that would minimize the merge work on multitty where we
have less active expertise to rely on.

Cc to K?roly and the multi-tty list.

In either case, a merge into trunk is quite a bit of work, so it would
certainly not do harm to ask Richard for the explicit goahead if we
can agree on the procedures.

The last updates of multitty appear to have happened on Apr 22nd.
K?roly, would it be possible for you to synch one last time to the
trunk and then check the results into a branch in Emacs CVS?

I would propose the following procedure:

a) K?roly synchronizes his version to the trunk [very desirable]
[after this has happened, we may already have word from list
participants and Richard whether we can agree on this procedure]
b) if he has CVS write access, he checks the results into a branch
emacs-multitty. If he hasn't, we need someone else to do this.
c) The branch is merged into the trunk. If point a had already been
done by K?roly, this will be trivial. If he has not been able to
do this, more work will be involved, but I don't expect serious
merge conflicts.
d) problems are shaken out. This will particularly affect platforms
not yet tested/implemented in multitty.
While d) happens, emacs-unicode2 is synchronized according to what the
developers of the branch feel appropriate. Synchronizing with the new
trunk will mean that there will be no production-quality
emacs-unicode2 until the trunk has stabilized again.
e) once the worst appears to be over, emacs-unicode2 is merged.

_Afterwards_, pent-up package updates reserved for "post-release" will
get merged.

This means that merge conflicts due to the multitty and unicode
changes will have to be tackled by the people checking in the package
updates.

Comments, better ideas?

[Jason Rumney]

Post by David Kastrup
However, I think we more or less agreed that it would be more prudent
to merge the multitty stuff first and follow up with the Unicode
branch, since that would minimize the merge work on multitty where we
have less active expertise to rely on.

I don't recall ever agreeing this, although you have asserted so
numerous times over the last few weeks.

The merge between multitty and unicode will be the same, whichever order
it is done in.
The simple fact is that emacs-unicode-2 is ready to go onto the trunk,
and the multitty is not due to issues mentioned in the README on
Karoly's website.

Post by David Kastrup
In either case, a merge into trunk is quite a bit of work.

I think in both cases, the branches are well synched with trunk already,
so there should be very little work in moving either one of the branches
to the trunk (though in the case of multitty it would break Emacs on
some platforms). The work comes when the non-merged branch is next
synched to the trunk. The conflicts will be the same whichever direction
the merge happens in, so I don't see any compelling reason to hasten the
multitty merge to trunk (but it should be checked in on a branch ASAP so
the problems mentioned above can be worked on by someone who is familiar
with the platforms affected).

Your point that Karoly is not going to be available for much longer is a
point against merging into trunk quickly IMHO. Either someone else will
step forward to maintain that code, in which case it doesn't matter if
the merge to trunk happens later, or noone wants to maintain the
multitty code, in which case merging into trunk would be a mistake.

[David Kastrup]

Post by Jason Rumney

Post by David Kastrup
However, I think we more or less agreed that it would be more
prudent to merge the multitty stuff first and follow up with the
Unicode branch, since that would minimize the merge work on
multitty where we have less active expertise to rely on.

I don't recall ever agreeing this, although you have asserted so
numerous times over the last few weeks.

Hm. Maybe the discussion was inconclusive.

Post by Jason Rumney
The merge between multitty and unicode will be the same, whichever
order it is done in.
The simple fact is that emacs-unicode-2 is ready to go onto the trunk,
and the multitty is not due to issues mentioned in the README on
Karoly's website.

I think we more or less agreed (modulo my possibly biased
recollections) that Emacs 23 should have the multitty functionality.
We are also not going to release Emacs 23 next week, and for people
needing a stable version of Emacs there will be EMACS_22_BASE
resp. Emacs 22.1.

So the trunk means the next place where work is going to commence. If
more work remains for the multitty branch, that would be reason to
merge it sooner. Another problem is that K?roly is not going to be
around to help much.

I have my doubts that if we merge unicode-2 first and postpone
multitty until all issues with it are resolved, the issues will never
actually get resolved. In particular when multitty is not kept
synched to the trunk after a unicode-2 merge.

So yes, I am aware that multitty will likely destabilize the trunk and
require work until the trunk is useful on all architectures again.

Which is sort of the point: take the multitty branch out of the
X11-only realm and have people work on making it a stable component of
trunk on all platforms.

I don't think that this is likely to happen in K?roly's private
repository, I really think that we need to merge it into the trunk for
a reasonable chance to have this happen.

Post by Jason Rumney
Your point that Karoly is not going to be available for much longer
is a point against merging into trunk quickly IMHO. Either someone
else will step forward to maintain that code, in which case it
doesn't matter if the merge to trunk happens later, or noone wants
to maintain the multitty code, in which case merging into trunk
would be a mistake.

I disagree with that assessment. It presumes that not making Emacs
multitty-capable ever is a reasonable option. But it is certainly
something that people have wanted for a long time, and it is an
embarrassing shortcoming as compared to, for example XEmacs which has
had this for very long. While I agree that a merge of multitty will
likely cause some problems, I don't think that "will work out of the
box" should be a criterion at the _start_ of the Emacs 23 process. We
are not aiming to release Emacs 23 simultaneously with Emacs 22.

multitty is quite an important aspect for operating Emacs as a server.
I don't think we should let the existing code go waste.

If we can't get to a more or less unanimous agreement between the
developers, it will be the call of Richard or a possibly apointed
Emacs 23 maintainer to make.

Of course, I would prefer if we could manage to reach more or less
consent without the need of reverting to authority.

[Jason Rumney]

Post by David Kastrup
I think we more or less agreed (modulo my possibly biased
recollections) that Emacs 23 should have the multitty functionality.

I am not arguing against including it in Emacs 23, I just think it is a
mistake to check code that is knowingly broken on some platforms into
the trunk.
I will put effort into getting it working again on Windows (assuming
noone else beats me to it), whether it is on a CVS branch or the trunk,
as I have done with emacs-unicode-2, but due to the time I have
available this could take a couple of months or more. I don't think it
is acceptable to have the trunk broken for that long, as it will prevent
some other developers who use Windows from helping with Emacs 23
development, if they do not have the w32 api experience to help with
fixing the multitty breakage, for example they may want to help with
some Lisp package.

I am not asking that it be flawless before merging, just that it isn't
horribly broken.

Post by David Kastrup
I have my doubts that if we merge unicode-2 first and postpone
multitty until all issues with it are resolved, the issues will never
actually get resolved. In particular when multitty is not kept
synched to the trunk after a unicode-2 merge.

Why would you not sync multitty to the trunk after the unicode-2 merge?
Surely Karoly, Handa and anyone else willing and interested should start
on resolving the merge problems as soon as possible. Even if we did the
multitty merge first, we would have the same problems on the unicode-2
branch, and would require the same people working on resolving them.

Post by David Kastrup
I don't think that this is likely to happen in K?roly's private
repository, I really think that we need to merge it into the trunk for
a reasonable chance to have this happen.

I agree that it won't happen in Karoly's private repository. I have
tried using it, but the revision control system he uses seems to be
unstable (from a user interface perspective), and the instructions he
gives for checking out no longer work. Reading the the latest quickstart
guide for bazaar did not really help. But committing it to a branch ASAP
would let the work commence on stabilizing it on other platforms ready
for merging into trunk.

Post by David Kastrup

Post by Richard Stallman
Your point that Karoly is not going to be available for much longer
is a point against merging into trunk quickly IMHO. Either someone
else will step forward to maintain that code, in which case it
doesn't matter if the merge to trunk happens later, or noone wants
to maintain the multitty code, in which case merging into trunk
would be a mistake.

I disagree with that assessment. It presumes that not making Emacs
multitty-capable ever is a reasonable option.

It is the only option if we don't have anyone willing to maintain that
capability. But judging from your activism on this, I don't expect we
will have that problem.

[David Kastrup]

I disagree with that assessment. It presumes that not making Emacs
multitty-capable ever is a reasonable option.

It is the only option if we don't have anyone willing to maintain
that capability. But judging from your activism on this, I don't
expect we will have that problem.

My "activism" does not make me a Windows, DOS, or MacOSX developer, so
it would not carry the day. While I don't remember a "horribly
broken" assessment either, it does not seem like I have the most
reliable of recollections about the details of the discussion.

I think it is more or less safe to say that it is about time to have
multitty moved into at least a branch in Emacs-CVS since development
in its own repository has IIRC been reduced mostly to synches, anyway.
Since its current version control system is arch-based, it sounds like
the way through the arch-variant of Emacs CVS that Miles proposed
would likely be the best way to do this: the person doing the move
would then work with a system he is familiar with on both ends.

[Kenichi Handa]

Post by David Kastrup
So yes, I am aware that multitty will likely destabilize the trunk and
require work until the trunk is useful on all architectures again.

At least, merging unicode-2 doesn't make the trunk unuseful
for any architecture, so I think it must be the first. It
may cause some problem, but it is just because that part is
not yet tested by any of unicode-2 users. Once the problem
is reported, I think I can fix it quite soon.

Currently Miles is synchronizing unicode-2 to the trunk
periodically (great thanks for that effort). If we merge
multitty to the trunk at first, and make the trunk unuseful
for some architecture, unicode-2 branch will also be
unuseful for that architecture after Miles synchronization,
which I do want to avoid.

Unicode branch has been there for more than 5 years, and we
should think that it is a kind of big bugfix for the current
weird/complicated character handling.

---
Kenichi Handa
handa at m17n.org

[David Kastrup]

Post by Kenichi Handa

Post by David Kastrup
So yes, I am aware that multitty will likely destabilize the trunk and
require work until the trunk is useful on all architectures again.

At least, merging unicode-2 doesn't make the trunk unuseful
for any architecture, so I think it must be the first.

That is assuming that the trunk should always be working for all
architectures. I have my doubts that this is the best way to make
progress. It certainly will be more convenient for people wanting to
_use_ the trunk as opposed to _work_ on it.

At the current point of time, the trunk _is_ more or less what people
are used to using for their everyday work, and snapshots are made from
it and provided as packaged, useful variants of Emacs.

I am not convinced that we will make speedy progress to Emacs 23 if we
insist on maintaining this state. I think that it is more reasonable
to have this sort of stability on release branches rather than the
trunk. In particular when we are talking about the _start_ of a new
version.

Post by Kenichi Handa
Currently Miles is synchronizing unicode-2 to the trunk
periodically (great thanks for that effort). If we merge
multitty to the trunk at first, and make the trunk unuseful
for some architecture, unicode-2 branch will also be
unuseful for that architecture after Miles synchronization,
which I do want to avoid.

A valid concern. It would probably make sense to cease the
synchronization while the work on multitty is stabilized.

Post by Kenichi Handa
Unicode branch has been there for more than 5 years, and we should
think that it is a kind of big bugfix for the current
weird/complicated character handling.

The concern seems to be that people want to have some more-or-less
stable version of unicode-2 that is kept up-to-date with other work.

If we merge unicode-2 first, the unicode-2 branch is dead. When
merging multitty afterwards, there will be no current variant of
unicode-2 without multitty.

Merging multitty first will leave us with the following:
a) a release (or release branch) for Emacs 22
b) a destabilized trunk containing multitty that needs to get brought
up to scratch on all platforms
c) a unicode-2 branch that continues to provide something from which
one can snapshot Emacs 23.0

Merging unicode-2 first will leave us with:
a) a release (or release branch) for Emacs 23
b) a trunk from which one should be able to provide Emacs 23.0
snapshots soonish, but without multitty.
c) a multitty branch that needs to get merged with the trunk now
containing Emacs 23.0

The second variant makes separate sense of its own mainly if one
_delays_ merging the multitty branch until it has stabilized on all
platforms.

I don't see that happening by magic.

In short: I am afraid that the second variant will be a "shortcut"
that will not lead to a faster release of Emacs 23, but rather provide
us with a longer "comfort period" on the trunk where the multitty
problems are not being addressed seriously.

[David Kastrup]

Post by Richard Stallman

Post by David Kastrup
Comments, better ideas?

It might be better to merge into the arch version of the trunk, and then
let that be committed to CVS. The multi-tty is already in arch, so
merging back into the arch-trunk should be basically trivial, and using
the regular arch->CVS gateway is probably safer than doing a one-off.

This sounds like a good idea.

[Richard Stallman]

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

[David Kastrup]

Richard Stallman <rms at gnu.org> writes:

[ K?roly wrote: ]

Post by Karoly Lorentey
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)?

Post by Karoly Lorentey
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.

[Kenichi Handa]

Post by David Kastrup
When are the unicode-2 people ready to merge, and would everybody else
be ok with this plan?

For me, unicode-2 merge can happen at any time because I've
been using only unicode-2 for long (except for the case of
debugging Emacs 22).

---
Kenichi Handa
handa at m17n.org

[Han Boetes]

Hurray! :-D

Post by Karoly Lorentey
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. 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.

# Han

[Dan Nicolaescu]

Post by Karoly Lorentey
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. 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.

How about considering the size of the code to merge before making a
decision?

For multi-tty the diffstat summary for the diff between multi-tty and
CVS HEAD is:
(I tried to exclude all the generated files, from the diff)

89 files changed, 5200 insertions(+), 2374 deletions(-)

For multi-tty a lot of the changes are mechanical: adding an extra
parameter to some function calls, adding an extra level of
indirection, etc.


For the emacs-unicode-2 the diffstat summary is:

271 files changed, 29930 insertions(+), 26730 deletions(-)

For multi-tty there have not been any reports of crashes in a long
time (more than a 1 1/2 years if I recall correctly).

Given that multi-tty is a much smaller change, and it touches a much
smaller area of emacs and that the unicode branch is a much more
fundamental change, it should be easier to stabilize the trunk after
merging multi-tty. So, IMHO, it would be more efficient to first
merge multi-tty and after that the unicode branch.

[David Kastrup]

Post by Dan Nicolaescu
For multi-tty there have not been any reports of crashes in a long
time (more than a 1 1/2 years if I recall correctly).

It does not work at all on several platforms as far as I understand
and thus would completely block the trunk for unrelated development.

[Dan Nicolaescu]

Post by David Kastrup

Post by Dan Nicolaescu
For multi-tty there have not been any reports of crashes in a long
time (more than a 1 1/2 years if I recall correctly).

It does not work at all on several platforms as far as I understand
and thus would completely block the trunk for unrelated development.

That has been know for several years, and it has not changed. And it
probably won't change until the branch is merged. Karoly says that
it's mostly fixing compilation errors. I would still guesstimate that
the total disruption would be less.

[David Kastrup]

Post by Dan Nicolaescu

Post by David Kastrup

Post by Dan Nicolaescu
For multi-tty there have not been any reports of crashes in a long
time (more than a 1 1/2 years if I recall correctly).

It does not work at all on several platforms as far as I understand
and thus would completely block the trunk for unrelated development.

That has been know for several years, and it has not changed. And it
probably won't change until the branch is merged.

There is no branch to merge yet. We first need to get it into a
branch. Then people will have a chance to work on it. At the moment,
it is only kept in a completely different repository.

Post by Dan Nicolaescu
Karoly says that it's mostly fixing compilation errors. I would
still guesstimate that the total disruption would be less.

I don't think it would be a good idea to merge it into trunk before
other people actually had a chance of assessing the problems and
working with them. Up to now, all we have about the other platforms
are guesses.

[Samium Gromoff]

At Sat, 12 May 2007 12:32:08 -0700,

Post by Dan Nicolaescu
For multi-tty there have not been any reports of crashes in a long
time (more than a 1 1/2 years if I recall correctly).

I'm all for multi-tty going in, as a user, but i have to say that
it was crashing pretty reliably for me, across many builds, in the past.

The current incarnation seems to be ok, so far, though.

regards, Samium Gromoff