[Top][All Lists]

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

Re: Merging multitty

From: Jason Rumney
Subject: Re: Merging multitty
Date: Fri, 11 May 2007 11:25:51 +0100
User-agent: Thunderbird (Windows/20070326)

David Kastrup wrote:
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.

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.

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.

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.

reply via email to

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