|
From: | Jason Rumney |
Subject: | Re: Merging multitty |
Date: | Fri, 11 May 2007 11:25:51 +0100 |
User-agent: | Thunderbird 2.0.0.0 (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 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.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.
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.
[Prev in Thread] | Current Thread | [Next in Thread] |