From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Fri, 29 Jul 2011 09:51:15 +0300 Message-ID: <8362mleg0s.fsf@gnu.org> References: <87mxgem09k.fsf@stupidchicken.com> <4E2A7EBD.7050300@gmx.at> <87livooqt6.fsf@stupidchicken.com> <4E2B158B.1080101@gmx.at> <87wrf8iyse.fsf@stupidchicken.com> <4E2BEED2.5040608@gmx.at> <8739hvu6lh.fsf@stupidchicken.com> <4E2C50E6.3020103@gmx.at> <878vrnweju.fsf@stupidchicken.com> <4E2D34D7.4040002@gmx.at> <87r55cjvef.fsf@stupidchicken.com> <87sjpsnerd.fsf@mail.jurta.org> <87d3gvqhkd.fsf@uwakimon.sk.tsukuba.ac.jp> <874o26rgq6.fsf@uwakimon.sk.tsukuba.ac.jp> <87zkjxq2zl.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1311922293 8282 80.91.229.12 (29 Jul 2011 06:51:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2011 06:51:33 +0000 (UTC) Cc: rudalics@gmx.at, cyd@stupidchicken.com, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 29 08:51:27 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qmgus-0006hj-Cd for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2011 08:51:26 +0200 Original-Received: from localhost ([::1]:57824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qmgus-0005xY-0F for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2011 02:51:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qmgup-0005xF-9s for emacs-devel@gnu.org; Fri, 29 Jul 2011 02:51:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qmgun-0000au-RY for emacs-devel@gnu.org; Fri, 29 Jul 2011 02:51:23 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:48570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qmgun-0000aI-Iz for emacs-devel@gnu.org; Fri, 29 Jul 2011 02:51:21 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LP300D001JOZ100@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 29 Jul 2011 09:51:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.48.51]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LP300DYG1P3X220@a-mtaout20.012.net.il>; Fri, 29 Jul 2011 09:51:05 +0300 (IDT) In-reply-to: <87zkjxq2zl.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142479 Archived-At: > From: "Stephen J. Turnbull" > Cc: juri@jurta.org, > rudalics@gmx.at, > cyd@stupidchicken.com, > emacs-devel@gnu.org > Date: Fri, 29 Jul 2011 10:39:42 +0900 First, let me make it clear that what I wrote earlier and what I will write in the future in this thread is by no means meant to be a criticism of Stefan's and Chong's style of leadership. I have nothing but deep respect for their work. In my case, wrt the bidi support, their constant encouragement to push this through and get the code merged onto the trunk and into Emacs 24.1 was definitely a great help. IOW, I don't intend to say that the current maintenance team does not do well what I think it should do. > > You will most probably disagree, but that's MO. > > I do disagree about policy (I think that it may be a good idea to > consider merging code like bidi, lexbind, and display-buffer at an > earlier stage on an explicitly experimental "we're probably going to > have to take it out, but we need to know what only the users can tell > us for future work" basis), but how is that "disrespectful"? If there's considerable doubt about the usefulness and/or quality of implementation or UI aspects of such a feature, that doubt should be eliminated to the large extent while the feature is still on a branch. Most large features like this underwent this process to some degree, and that is fine. Once the merge happens, the decision to revert should be the last resort, not part of a "trial-and-error" routine of some kind. In my case, I worked for 2 years on bidirectional display. That involved a lot of effort, sometimes at considerable personal price. Telling me now that this will be reverted _will_ have certain unpleasant effects on my mood, to put it mildly. If someone would request me to do that, I will have a moral right to ask where were they for the past year and a half, since the bidi code was merged onto the trunk, and why didn't they take a good look at it, try it out, ask questions etc. If I did a poor job, I'd like to hear that back then, and cut my losses, or go back to the drawing board and come up with a better design or implementation. I don't know how long it took Martin to do what he did with window-level display features, but I'm certain it was longer than a day or a month. I don't remember how long was the code available on a public branch, but it wasn't a day or a month, either. I expect Martin to have similar feelings about reverting it now. I think I already saw an expression of these feelings in his messages lately. I don't think we should trigger such feelings, except if that's the only way to prevent some disaster. IOW, developing software by volunteers is a social process, no less than it is a technical or managerial one, I'm sure you know that. Reverting some significant contribution is not just a technical decision, because it has profound social and emotional consequences. More generally, the GNU Project's goal is to make a better world, not just better software. You cannot get there by disregarding people you meet on the way, just because that might make maintenance or "progress" a tad harder. But I digress. > Note that I didn't propose that people discount the maintainers' > considered opinions, only that they not argue against reversion simply > because it means changing code that's been approved. IMHO it's more > disrespectful to suggest that the maintainers can't change their minds! I wasn't talking about just _any_ code reversion, we do that all the time. I was talking about significant features that took a long time and a significant effort to implement and tune, and that had been publicly available for quite some time. When we are past a certain quantity of effort, there's a need for a qualitatively different decision-making process regarding reversion, IMO. > Anyway, the word "experiment" is appropriate until you propose a more > accurate one that takes into account both the maintainers' approval > and the uncertainty of success. The point is that certainty of success should be quite high as a prerequisite for approving such significant features for a merge.