Re: Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)?

[Max Nikulin]

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.