From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Feature freezes and Emacs 25 Date: Wed, 11 Nov 2015 02:17:32 +0200 Organization: LINKOV.NET Message-ID: <87oaf1s82r.fsf@mail.linkov.net> References: <56259FDD.8040401@dancol.org> <87zizeme8k.fsf@tromey.com> <5625B166.3080104@dancol.org> <86zizdczhp.fsf@stephe-leake.org> <871tc315y3.fsf@lifelogs.com> <83k2pvqg0l.fsf@gnu.org> <837fluqkd1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447203674 4883 80.91.229.3 (11 Nov 2015 01:01:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 01:01:14 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 02:01:06 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwJma-00083M-BR for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 02:01:04 +0100 Original-Received: from localhost ([::1]:36758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwJmZ-0000DX-E6 for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 20:01:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwJPL-0006Hp-CI for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:37:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwJPI-0006VS-5U for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:37:03 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:41668 helo=homiemail-a17.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwJPH-0006Ux-WE for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:37:00 -0500 Original-Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 9B7082B206D for ; Tue, 10 Nov 2015 16:36:55 -0800 (PST) Original-Received: from localhost.linkov.net (m212-53-104-68.cust.tele2.ee [212.53.104.68]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id DBAD22B206A for ; Tue, 10 Nov 2015 16:36:54 -0800 (PST) In-Reply-To: (John Wiegley's message of "Mon, 09 Nov 2015 13:55:08 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 69.163.253.7 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:194012 Archived-At: >> I think we should first decide whether new features that are "almost ready" >> should or should not be in 25.1. Two examples that immediately come to mind >> are dynamic loading and xwidgets; I don't know if there are others. After we >> make the decision, we could see if one week's time is enough. > > I'd like to see both of those in 25.1. > > Let's freeze this Friday, and take a step back. We have several courses open: > > 1. Decide that what we have now should become 24.6. > > 2. Decide it will become 25.1. > > 3. Decide that we want to bring in more features that aren't yet complete, > and so push the freeze to a future date. John, could you please extend the deadline of the feature freeze a little since I have no chance to commit all changes until Friday. Basically what I'm doing is the same kind of work as Alan's efforts in bug#17453. While Alan is designing a framework to support multiple windows by adding a new arg with a group of windows, I'm designing a framework to support multiple regions by adding a new arg with a group of regions. In bug#19829 I've collected the evidence of commands that need this feature as a basis for the new design, but the deadlock was caused by the same question that backpedaled the Alan's design: whether to add a new arg to the existing functions or to try stuffing it into the existing ones?