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: Fri, 03 Feb 2017 17:05:44 +0100 Message-ID: <87poiz2raf.fsf@engster.org> References: <87k29d7zvw.fsf@engster.org> <87fuk08i01.fsf@engster.org> <87d1f36xnc.fsf@engster.org> <87a8a4ees0.fsf@engster.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZgN0-0006Ll-NK for emacs-orgmode@gnu.org; Fri, 03 Feb 2017 11:05:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZgMw-000788-Mp for emacs-orgmode@gnu.org; Fri, 03 Feb 2017 11:05:54 -0500 In-Reply-To: (John Wiegley's message of "Thu, 02 Feb 2017 20:54:39 -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> So if you don't get convinced, we'll just move again, right? No big deal. > > I suppose I'm asking that of you, yes. Sorry, but I rather wait. > DE> You are insinuating that my motivation is to delegate CEDET development to > DE> the core Emacs developers. This is simply not true, and I don't see how my > DE> original mail could be interpreted like that. > > I didn't mean to insinuate anything; it seems we may have gotten off on the > wrong foot, my intention is to make your life easier, not harder. If all this > would do is make more work for people, it's not worth it. This will most definitely make things harder for me. > DE> So let me try again: What I find completely misguided is to move packages > DE> out of core *but still putting them into the release*. In other words, in > DE> my opinion there are really just two options that make sense: you either [+] > DE> keep a package in core, or you kick it out and don't ship it with the > DE> release. > > Why is this so? Right now I see the Emacs release as more than just releasing > Emacs core; it's more of a "batteries included" release, combining the editor > with lots of other default packages. It makes sense to me to move these > batteries outside the core repository, than to put them all together in the > same Git repository. For package developers, keeping up with Emacs has become much harder in recent years, as its development has accelerated (which is a good thing). 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). 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. > We can arrange things so that a Git clone of Emacs includes pulling the > submodules (or trees, or ELPA.git, or what not) that are considered part of > "main Emacs development", including some of those batteries. I see this all as > a process issue, and that "living in one Git repository" has just been an > implementation strategy to satisfy that process. Obviously, I'm very skeptical towards such an approach. Our tooling around Emacs development is already very intricate and only works because a few people work quietly behind the scenes to keep this all running. Introducing even more complexity through submodules/subtrees/whatever will do the opposite of what you want to achieve: it creates more work for those few people who manage the Emacs infrastructure. But I'd love to hear what for instance Glenn and Paul think about this. > Why do the split at all? Core becomes smaller, First off, the Emacs repo isn't that big w.r.t. the number of files. Secondly, while there surely is an inverse correlation between repo size and maintainability, I would argue that as long as the Big Three are well maintained, they are not the problem. When did CEDET, Gnus or Org ever significantly delay an Emacs release? When was an Emacs core developer ever forced to fix a critical thing in those packages he did not break? These are the questions we should be asking. From watching this list over the past years, I don't get the feeling that the inclusion of these packages has been a significant burden, but I may be wrong. > its future history less cluttered, That's actually a bit funny, since we gave up an uncluttered history when we switched to git's spaghetti DAG. > updating packages within it is no longer a major issue, and (I hope) > it will be clearer when something is a core issue vs. a package issue. I find this whole core vs package argument strange. If you ship Emacs with Org, Gnus and CEDET, they are part of Emacs, so it's in the interest of all Emacs developers that they work well, whether they use them or not. The users won't care if they originate from a separate repo and are considered a "package". So if Paul is determined to fix all occurences of "compatilibity" in the doc-strings, why would he only do that for core? People won't care if it's a CEDET doc-string, they'd just say "Teh Emacs people cant spell!1!!". It's no big deal for him anyway if everything is in one repo. Likewise when Stefan does some refactoring, like renaming 'defmethod' to 'cl-defmethod'. Doing this for all files is a matter of seconds, then commit, done. If Gnus, CEDET and Org are separate, you have to create separate commits for them, with their own ChangeLogs. I would argue that it is almost always *less* work for all people involved if things get fixed right away from the right person, and putting our built-in packages in different repos will make this more difficult. > DE> Say the Python developers would decide: Hey, many people like Django, so > DE> let's just put their latest git master into our release and ship it. Would > DE> you think that is a good approach? > > Some companies have actually done this. I remember when ActivePython bundled > quite a few things, making it an attractive alternate to installing core > Python (back when package management was still very poor in Python world). The question is *how* did they do this. You think they just copied it over and hoped for the best? Or maybe they did have one repo were everything was checked in, and where they carefully tested it, maybe even applied their own patches to Django which they couldn't or wouldn't get upstream? I don't know! Since it is non-free, we cannot check, unfortunately. -David