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

[Max Nikulin]

On 08/09/2021 09:02, Po Lu wrote:
> Max Nikulin writes:
>
> > There is a technical reason why github is not suitable for Linux
> > kernel (and it is hardly to applicable to Emacs): it is impossible to
> > coordinate several groups of developers responsible for different
> > subsystems using github flavor of pull requests and bugs. For email it
> > is simply several Cc addresses:
>
> Why do you believe that is not applicable to Emacs?  Similar to the
> Linux kernel, Emacs is a large project with many subsystems that stretch
> across a great amount of expertise domains.

Sorry, I forgot that Emacs is a kind of OS, so it requires equal treatment.

More seriously, it is no more than my impression, so I admit, it may be 
wrong.

Let's leave aside web UI vs. email aspect and concentrate on joining 
groups and moving discussion or bug to another group feature.

Judging from

    git log --since 2020-09-01 --pretty="format:%an" \
        | sort | uniq -c | sort -n

number of really active authors (and committers, %cn) is not so high (25 
developers with more than 20 commits). Development of kernel is much 
more active and splitting into groups is mission critical otherwise 
noise for each person would be too high.

Does Emacs have many mail lists dedicated to *development* of subsystems 
(in other words, are there several apparent groups working on the same 
repository)? Traffic in emacs-devel is high enough (roughly 1500 
messages per month) however I am unsure that it is possible to split 
into several mail lists with more narrow subjects.

I do not say that discussion never moves from one group to another. E.g. 
recently cause of Org mode related problem was traced down to native 
compilation bug. Tight collaboration of two groups was not necessary 
however. Ability to just add "Cc" is convenient but while such events 
are not frequent above, cost of separate tracking and discussions is 
acceptable.

There are no defined criteria when it is better to split development 
into relatively independent groups. Till such groups appear the feature 
of coordination is not really important. (Features necessary for Emacs 
developers are highlighted in sibling threads.)