From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Engster Subject: Re: Sync up the org in emacs master to org maint branch? Date: Tue, 31 Jan 2017 16:45:43 +0100 Message-ID: <87d1f36xnc.fsf@engster.org> References: <87k29d7zvw.fsf@engster.org> <87fuk08i01.fsf@engster.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYacv-0001D2-QI for emacs-orgmode@gnu.org; Tue, 31 Jan 2017 10:45:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYacs-0008JF-NM for emacs-orgmode@gnu.org; Tue, 31 Jan 2017 10:45:49 -0500 In-Reply-To: (John Wiegley's message of "Mon, 30 Jan 2017 16:52:22 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Kaushal Modi Cc: Bastien Guerry , Phillip Lord , emacs-org list , Emacs developers John Wiegley writes: >>>>>> "DE" == David Engster writes: > > DE> It is a mistake because you are creating more moving targets and bring > DE> them together very late in the release process. This reduces the amount of > DE> testing that is done for those packages, so bugs will be noticed later and > DE> the quality of the relases suffer. It moves even more work into the > DE> RC-phase, which is already crowded and where people who can fix those bugs > DE> might not be readily available. It removes those packages from Emacs CI, > DE> so that breakages due to changes in core are not immediately noticed, and > DE> often times they have to be fixed not by those who created the breakage, > DE> but by those who notice them. > > These are issues to be fixed in the way ELPA integrates with our development > process. I recognize today's ELPA may have these drawbacks, but I believe they > can be fixed. This really has not much to do with how ELPA works. My points above are about the underlying concept you are proposing: moving packages out of Emacs core and hence removing them from current Emacs development, but still bundling them with the release. It's a have-and-eat-cake concept. > We're moving toward a future where Emacs.git will represent "core Emacs", and > only contain what core needs (plus a few historical bits, I'm sure). There > should be no argument for keeping a project in core just to gain auxiliary > benefits. Of the points I raise above, which fall under "just to gain auxiliary benefits"? I'm honestly confused. I'm specifically talking about the quality of the Emacs relases. Also, I currently have no idea how to continue with CEDET, as the future where development should happen is unclear, and I get the feeling we're just waisting our time with the ongoing merge. -David