|
From: | Max Nikulin |
Subject: | Re: Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)? |
Date: | Thu, 9 Sep 2021 00:34:03 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
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 -nnumber 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.)
[Prev in Thread] | Current Thread | [Next in Thread] |