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: Sun, 05 Feb 2017 22:36:48 +0200 Message-ID: <871svcxtlr.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <871svcinf3.fsf@engster.org> (David Engster's message of "Sun, 05 Feb 2017 17:59:28 +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 >>> 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 don't know what you have in mind. All I can say is: CEDET couldn't do > what it does if we'd restrict ourselves to some subset of Emacs. In particular I was worried by the phrasing "extremely dependent". I agree that in order to make a system like CEDET without re-inventing the wheel and without running into performance problems it's necessary to depend on more primitive parts of Emacs. Perhaps we can improve the relationship(?) Perhaps this is a discussion to be had when all of this is done though. >> I feel like this problem isn't intractable. > > I didn't say it's intractable. I just said it means more work for me. > >> 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. > > As I said: we did that. It was a huge amount of work. Please understand > where I'm coming from: if you look through the CEDET history, you will > see that in the past few years I almost exclusively did infrastructure > work and no real coding. All I can say is: *I* won't do this anymore, > and I don't want to be part in something which will increase grunt > work. We did not make this decision lightly. But with the amount of > developers we have, I'm convinced it's the right thing to do. Fair enough. I don't have the experience here. It just seems like we could meet both goals without increasing the work load in this regard. To be clear I agree that, whatever decision this discussion arrives at, we definitely don't want to we waste the time of any developer with grunt work. Continuing this line of thought. I'm not sure that we're thinking of the same process here. What I'm suggesting is as follows: - 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 - 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. Also, would this be a problem for our users? i.e. would we be inundated with emails requesting continued support on older versions or would users generally accept this kind of change. I mostly work on back end systems so I don't have a good feeling for how this would go down with users (I would find this reasonable as a user). > Bug fixes can go with point release, which we should have every > year. But yes, if you want the latest, greatest and buggiest, you'll > have to use Emacs master. But that goes for a lot of Emacs features, so > I don't see why it's particularly bad for CEDET. I feel like there are aspects of CEDET which are still under development. Perhaps I'm just unlucky in my particular usage patterns of upstream and the way things are going this will be fine (with the un-merged parts going into packages.) >> I'm interested in exploring more with regards to how the subtree >> approach would work. In particular how it would impact the Makefiles >> and build process. I don't think that introducing features like this >> necessarily increases the burden of maintaining our tooling. If we get >> it right it could reduce it. > > 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. >> I think that it's a worthwhile goal to make core smaller. It may not be >> a gigantic enterprise system with tens of thousands of source files, >> like some of us are accustomed to working on, but I think that it >> becomes easier to reason about the features and behaviour of core when >> it's smaller. > > 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 that the distinction becomes clearer when you consider what >> other parts of Emacs ought to be able to depend on. If mode-x started >> building dependencies on CEDET because the author discovered some useful >> functions in CEDET. Then mode-x would build a dependency which is >> difficult to maintain because changes in CEDET might have unintended >> effects on mode-x. If the function really is useful, then I think >> that we should instead consider extracting it from CEDET and placing it >> into some core library. As far as I can tell this has already happened >> with numerous functions which originated from CEDET. > > Aside from EIEIO, I wouldn't know any. And with EIEIO it had exactly the > opposite effect: CEDET has to adapt, not the other way round. I think that we missed each other here. I was saying that moving EIEIO out of CEDET and giving it a home where other packages could depend on it was a good thing and that CEDET has to adapt to changes in EIEIO is the way it should be. I can think of one other function off the top of my head: `locate-dominating-file'. I believe that it came from EDE. >> I don't think that anyone is suggesting that we "copy them over and hope >> for the best." This would have to form part of the QA process. As for >> testing -- I would be surprised if CEDET in core has really received the >> amount of testing it needs to declare that it's a stable release. > > Well, that's precisely why I want to move development to the Emacs > repository. 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. Kind regards, Edward Steere