From mboxrd@z Thu Jan 1 00:00:00 1970 From: Edward John Steere Subject: Re: Sync up the org in emacs master to org maint branch? Date: Tue, 07 Feb 2017 19:18:04 +0200 Message-ID: <8737fphqcz.fsf@gmail.com> 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> <871svcinf3.fsf@engster.org> <871svcxtlr.fsf@gmail.com> <87zihzf03g.fsf@engster.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <87zihzf03g.fsf@engster.org> (David Engster's message of "Mon, 06 Feb 2017 23:03:47 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sender: "Emacs-devel" To: David Engster Cc: Bastien Guerry , Emacs developers , Phillip Lord , emacs-org list , Kaushal Modi List-Id: emacs-orgmode.gnu.org >> - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then >> released; CEDET is at >> - we update a registry somewhere indicating that Emacs 22.0 works with >> and 22.1 works with >> >> - When we make updates to CEDET we mark 22.1 as working with >> but we don't change that reference >> for 22.0 (or any older versions) >> - When someone complains that there's a bug in CEDET for 22.0 we >> indicate that it's no longer supported and that they should update >> Emacs to receive updates >> >> This process would almost be the same as what you get just by bundling >> CEDET with Emacs except that: >> >> - You can get the latest CEDET *if* you have the latest Emacs > > No. We have two branches: emacs-25 and master. The CEDET from master > will usually not work on any 25.x version. In the process which I proposed we would be developing against the most recently released Emacs. I now see that there's a trade off. If we were to go with my scheme then users would have access to the latest version, but we would: 1. miss out on the new features being developed on the Emacs master branch (which CEDET stands to gain a lot from); 2. have to endure a difficult and error prone release process every time Emacs is released because that's not what all the testing is done against; If we go ahead and merge it in then we would be able to benefit from all the new Emacs features and the release would be less painful. Of course our users would still have to wait for the latest features, but at least it would be worth the wait because we would be able to consider using features like threading. >> - The version of CEDET for any particular version of Emacs is as far as >> CEDET got before the next release of Emacs came out >> >> If this is what you were thinking of then please could you elaborate on >> what ended up being the problem which added more work. > > First off, CEDET is currently *not* a package, although that notion gets > thrown around a lot. It is scattered across the Emacs code base: > lisp/cedet, admin/grammars, etc/srecode, documentation, and test > suite. All this needs to be packaged in a way so that it can be > integrated into Emacs during a normal checkout. It needs to build and > test in such a normal checkout, but also separately when installed from > ELPA, including grammar compilation. And you need this twice: one for > emacs-25, one for master, with the possiblity to merge between the two. Yes, this would be a pain. I'm in favour of Phillip's approach in which the packages are self contained somewhere in the Emacs source tree. This would eliminate the need for a complicated copying process and eliminate the problem of where things go and what files should be updated. No other folder would be touched because a package contains it's own source, documentation etc. Unfortunately the idea isn't gaining a lot of traction. I'm not satisfied that the alternative would make things easier for anyone because, as you say, it would need to describe a complex copying process which intertwines CEDET with various parts of Emacs. > Then there's this "registry". No one has said how that should > work. "Submodules/Subtrees" are *not* a sufficient answer, they are just > tools. People will need to say how the *workflow* should be, including > such things like merges from stable, ChangeLog generation, AUTHORS, > NEWS, creating release tarballs, and so on. Once someone has written > this down *in detail*, we can discuss again if this indeed will make > things simpler and reduce our workload. I haven't heard the registry mentioned before. I mentioned it as a detail required by my process for supporting multiple versions, but I'm beginning to think that it's the wrong line of thought to pursue. >>> Well, we cannot really discuss this since there's no real plan how this >>> all should work. I can only speak from experience. >> >> We can still put ideas forward though. Haven't come up with anything >> myself yet though. > > Yes, you can, but it has a cost. Once again, the CEDET merge is stalled, > and we spend our time writing mails. I find this situation incredibly > frustrating. In lieu of any input from others the best we have is Phillip's idea of using Elpa. That solves how the files are copied in and compiled. >>> How does CEDET, Gnus and Org affect the rest of Emacs? They strongly >>> depend on Emacs "core" (whatever exactly that is), not the other way >>> round. >> >> I believe that one of the intentions of the move is to enforce this so >> we can't build bad dependencies -- am I wrong? > > I think other modes should use Semantic. Agreed. I mentioned this in my response to Stefan's email. Shouldn't we then consider moving it out of CEDET in Emacs? >> Perhaps I'm wrong, but to my mind the package approach would afford us >> with more testing before we get to the point of another release of >> Emacs. > > If you develop on Emacs 'master', you can use all the new features (like > threading and FFI), but you loose testers on 25.x. A package won't > change that. Yes. As I said earlier in this email I'm now starting to appreciate this problem. Perhaps it's worth considering which aspects of CEDET would really benefit from being integrated with Emacs and which could live without the latest features (and be turned into packages). There are four parts to CEDET which I'm aware of (at least in the CEDET which is included in Emacs): 1. Semantic 2. Semanticdb 3. EDE 4. Srecode I think that the key parts are Semantic and Semanticdb. What if we merged Semantic and Semanticdb into Emacs proper (i.e. not under a folder named cedet in the source tree) and worked on turning EDE and Srecode into packages which are included for distribution? The only obstacle I can think of is that there are some features in Semantic (ia and db) which rely on project variables (such as the location of system includes). We could consider decoupling Semantic to solve this problem. e.g. by providing an interface to which other modes can publish known information about the context of a source file in a project.