|
From: | Max Nikulin |
Subject: | Re: Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)? |
Date: | Mon, 20 Sep 2021 00:01:41 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
On 17/09/2021 04:03, chad wrote:
This is a small thing, but: On Thu, Sep 16, 2021 at 10:25 AM Max Nikulin wrote: My opinion is the following: [...] - The reason why current web UIs are not sufficient for Linux kernel is not applicable for Emacs. There are a lot of independent groups involved into kernel development while Emacs does not have such fragmentation so flexibility in respect to groups is unnecessary.I suspect that people who think this have never tried to follow, for example, gnus, CEDET, or org development as part(s) of GNU emacs. These are more common in the Linux kernel, but the core motivations exist in both projects, and it would be great to have improvements even if they aren't adopted by both.
Is it frequent enough case that some feature requires synchronous changes in Emacs core and Org (similar to changes in drivers and subsystems of Linux kernel)? If not, projects may be considered rather independent. Some linux drivers are independent to some degree as well, however changes in some kernel subsystem may require support of several versions of driver with different ranges of compatible kernel versions.
Sometimes fixes in Org are necessary in response to changes in Emacs to avoid compiler warnings. On the other hand Org still declares compatibility with Emacs-24.3 that, in my opinion, means quire loose coupling.
If tight collaboration is required only in rare cases, cost of tracking of bug/feature in an "external" project is not significant. It is not unusual when developers from one project to interact with developers of e.g. completely independent library. Some tools may be handy though, e.g. bugs.launchpad.net subscribes to external bug trackers to show discussion as comments to "local" issue.
I have an example of change in Emacs that can make Org better. Several hundred of markers severely slows down regexp searches in the buffer (at least in Emacs-26.3). Org may cache e.g. heading positions using markers. Improving handling of markers in Emacs will make Org more responsive. No action on the Org side is required though (besides a bug report). It just will work faster with new Emacs versions than with older ones.
I believe, it is great that each project (Emacs, Org mode) can have own pace of development making requirements for development tools not so strict.
[Prev in Thread] | Current Thread | [Next in Thread] |