From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.orgmode,gmane.emacs.devel Subject: Re: Sync up the org in emacs master to org maint branch? Date: Sun, 05 Feb 2017 17:50:38 +0200 Message-ID: <83zii07i29.fsf@gnu.org> References: <87k29d7zvw.fsf@engster.org> <87fuk08i01.fsf@engster.org> <87d1f36xnc.fsf@engster.org> <87a8a4ees0.fsf@engster.org> <87poiz2raf.fsf@engster.org> <871svdrov0.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1486309886 18405 195.159.176.226 (5 Feb 2017 15:51:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Feb 2017 15:51:26 +0000 (UTC) Cc: deng@randomsample.de, emacs-devel@gnu.org, bzg@gnu.org, emacs-orgmode@gnu.org, kaushal.modi@gmail.com, phillip.lord@russet.org.uk To: Edward John Steere Original-X-From: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sun Feb 05 16:51:22 2017 Return-path: Envelope-to: geo-emacs-orgmode@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caP60-0004Vw-8t for geo-emacs-orgmode@m.gmane.org; Sun, 05 Feb 2017 16:51:20 +0100 Original-Received: from localhost ([::1]:43635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caP65-0001tw-Rq for geo-emacs-orgmode@m.gmane.org; Sun, 05 Feb 2017 10:51:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caP5e-0001tr-6K for emacs-orgmode@gnu.org; Sun, 05 Feb 2017 10:50:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caP5c-0008Al-Rc for emacs-orgmode@gnu.org; Sun, 05 Feb 2017 10:50:58 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caP5X-00086s-9r; Sun, 05 Feb 2017 10:50:51 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3658 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1caP5V-00027b-JA; Sun, 05 Feb 2017 10:50:50 -0500 In-reply-to: <871svdrov0.fsf@gmail.com> (message from Edward John Steere on Sun, 05 Feb 2017 11:03:31 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.21 Precedence: list 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 Original-Sender: "Emacs-orgmode" Xref: news.gmane.org gmane.emacs.orgmode:111931 gmane.emacs.devel:211997 Archived-At: > From: Edward John Steere > Date: Sun, 05 Feb 2017 11:03:31 +0200 > Cc: Bastien Guerry , Emacs developers , > Phillip Lord , > emacs-org list , > Kaushal Modi > > > It's not like packages communicate with Emacs over a well > > defined RESTful interface. In other words: CEDET and Gnus are not > > loosely coupled, quite the opposite: they are extremely dependend on > > many obscure Emacs internals (not sure about Org). > > Shouldn't we be trying to avoid this situation? It's sure to come back > and bite us in the future. If we continue to develop a package > (wherever it ends up being developed) which is so tightly coupled that > any kind of re factoring in core becomes a nightmare, because we have to > consider the umpteen ways in which it'll break the package, then surely > that's a bad methodology to continue? (I'm not suggesting that we > rewrite it to make it more loosely coupled, just that it seems like a > bad idea to continue allowing this going forward.) How would you go about not allowing this to go forward? I don't think I see any practical way to do that; do you? IMO, this is up to the package developers: if they want to depend less on the Emacs internals, and thus be more loosely coupled with a particular Emacs version, they will need to invest the extra effort for that, e.g., by providing some compatibility shims. IOW, this isn't an issue that can be solved once and for all by the way we develop the core or the packages, or by the way we integrate packages with core, the solution is on a different level. > > As a consequence, we > > and also the Gnus guys decided to not do separate releases anymore. We > > used to provide CEDET for different Emacs versions, and it was a *huge* > > amount of work. I had a buildbot running with 7 or 8 Emacs versions to > > run the test suite, and things broke pretty regularly. > > Now you might say: fine, only release a package for current master. But > > let's say we put CEDET into ELPA. Emacs 26 gets released, and work on > > Emacs 27 starts. Now there are changes happening in Emacs 27 that > > require changes in CEDET, which make it incompatible with Emacs 26. So > > you have to create two packages: one for 26, one for 27? Not only is > > this confusing, but it most definitely increases my workload. > > I feel like this problem isn't intractable. We can mark some state of > CEDET as being stable under the various versions of Emacs (because it > was at the time) and then only support the current release for the > latest package. This would most likely require changes to package to > ensure that you get an appropriate version of the package when you > download it. IF (and its a big "if") package developers want to be able to target more than the single Emacs version on a single branch of the Emacs repo, then they will need to provide at least 3 branches: . "development" branch that tracks the Emacs master branch and introduces exciting new features . "bugfix" branch that tracks the Emacs release branch without adding any new features . "stable" branch that is compatible with the Emacs release branch, but also introduces some new features, the ones that don't need core developments available only on the Emacs master branch I envision that some packages will want the above (or maybe even a more elaborate scheme), because they can afford that, and because their users expect that. These are mostly those packages whose developers welcome the move to put more of Emacs on ELPA. Other packages, and I guess CEDET is one of them, will not want to do this, because it adds too much work to an already complicated and time-consuming job. IOW, once again the solution is not part of the way we develop the core or integrate non-core packages, it's elsewhere. Bottom line, I think people are bothered by aspects of the "move to ELPA" process that are not supposed to be affected by that move in any way. They are aspects that need to be resolved on entirely different levels, and the resolution is up to the package maintainers. That includes a possible decision of the developers that some package will not move to ELPA; I don't think that if a package developers say they want to stay in emacs.git, they will be told to get out regardless.