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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> 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.)

I think the discussion sort of got off track from where it started.

This was all kicked off by an observation that the current workflows may
not be sufficiently familiar/clear for new contributors or that they
discourage contributions from new contributors rather than with any
perceived problem with workflows once a submission has been made. My
impression is that the 20+ people who actually do all the work of
reviewing and merging contributed patches are quite happy (in the main)
with the current workflow.

To be proposing a whole new workflow just to facilitate the first step
i.e. contributing a patch, seems to be a little too much and feels like
it cold run the risk of throwing the baby out with the bathwater.

Perhaps the answer is to look at how things can be structured to make it
easier for people to submit quality patches (patches with sufficient
documentation, test cases, correct formatting etc) while minimising
disruption to the rest of the workflow rather than wholesale
re-engineering of the total process.