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

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

[Hongyi Zhao]

Nowadays, the large software projects often conduct the development on
the workflow supplied by git  forges (GitHub, Bitbucket, GitLab,
etc.). But it seems that Emacs is still developed directly on git, as
described here [1], which makes maintaining GNU Emacs development a
lot of extra work.

So, why not set Emacs development workflow based on the popular git forges?

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html.

Regards
-- 
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Sat, Sep 04, 2021 at 02:55:35PM +0800, Hongyi Zhao wrote:
> Nowadays, the large software projects often conduct the development on
> the workflow supplied by git  forges (GitHub, Bitbucket, GitLab,
> etc.). But it seems that Emacs is still developed directly on git, as
> described here [1], which makes maintaining GNU Emacs development a
> lot of extra work.
> 
> So, why not set Emacs development workflow based on the popular git forges?

There is an enormous discussion about this in this very mailing list
(starting around endo of August and still ongoing, with well over
300 posts.

Are you aware of it? Perhaps there might be some iteresting aspects
in there for you.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Po Lu]

> Nowadays, the large software projects often conduct the development on
> the workflow supplied by git  forges (GitHub, Bitbucket, GitLab,
> etc.). But it seems that Emacs is still developed directly on git, as
> described here [1], which makes maintaining GNU Emacs development a
> lot of extra work.

GitHub, Bitbucket and GitLab require their users to run non-free
software, which already disqualifies them for the development of GNU
software.

There was recently a discussion (perhaps it is still in progress? I
don't know) about moving to SourceHut, but I don't think it's gone
anywhere.  The problem seems to be that the present system exists and
works, while nobody has sat down and completed the work required to
migrate to a new one.  Would you like to volunteer? :D

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Sat, Sep 04, 2021 at 07:24:21PM +0800, Po Lu wrote:
> > Nowadays, the large software projects often conduct the development on
> > the workflow supplied by git  forges [...]

[...]

> There was recently a discussion (perhaps it is still in progress? [...]

It is. It seems to converge towards a Gnu hosted instance of Sourcehut.

Even Sourcehut's main developer took part in it. So folks, look into
the archives :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Po Lu]

<tomas@tuxteam.de> writes:

> Even Sourcehut's main developer took part in it. So folks, look into
> the archives :-)

Thanks, but I can't possibly look through every post in the archives.
Could you point me to a relevant piece of the discussion?

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Sat, Sep 04, 2021 at 07:38:24PM +0800, Po Lu wrote:
> <tomas@tuxteam.de> writes:
> 
> > Even Sourcehut's main developer took part in it. So folks, look into
> > the archives :-)
> 
> Thanks, but I can't possibly look through every post in the archives.
> Could you point me to a relevant piece of the discussion?

The thread starts about here [1], and it has made children.
It is so huge that I'm surprised anyone here has't seen it
yet.

I don't think it's a good idea nor productive to make even
more children :)

Cheers

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-08/threads.html#01134

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Hongyi Zhao]

On Sat, Sep 4, 2021 at 7:24 PM Po Lu <luangruo@yahoo.com> wrote:
>
> > Nowadays, the large software projects often conduct the development on
> > the workflow supplied by git  forges (GitHub, Bitbucket, GitLab,
> > etc.). But it seems that Emacs is still developed directly on git, as
> > described here [1], which makes maintaining GNU Emacs development a
> > lot of extra work.
>
> GitHub, Bitbucket and GitLab require their users to run non-free
> software, which already disqualifies them for the development of GNU
> software.

If so, I don't think there is such a complete free platform in the
world, even the SourceHut you mentioned below, which is also operated,
at least in part, as a commercial product. OTOH, Linux kernel [1] has
already adopted GitHub as its development platform, which is also
complete free and a classic example of successful free software.

> There was recently a discussion (perhaps it is still in progress? I
> don't know) about moving to SourceHut, but I don't think it's gone
> anywhere.  The problem seems to be that the present system exists and
> works, while nobody has sat down and completed the work required to
> migrate to a new one.

I can't say anything. Almost all Emacs developers and users are
excellent programmers/scientists/engineers. But excellent people also
have their own beliefs, quirks and their inner bottom line. Sometimes
it may not be consistent with the prevailing trend, just like the
existence of Emacs itself.

> Would you like to volunteer? :D

Technically speaking, I think there are so many guys in Emacs
community have enough ability to do this.

[1] https://github.com/torvalds/linux

Best, Hongyi

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

[Po Lu]

tomas@tuxteam.de writes:

> The thread starts about here [1], and it has made children.
> It is so huge that I'm surprised anyone here has't seen it
> yet.

I remember participating in the parent, but I didn't see anything
pertaining to SourceHut at the time.  Thanks!

> I don't think it's a good idea nor productive to make even
> more children :)

Indeed, thanks.

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

[Po Lu]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> If so, I don't think there is such a complete free platform in the
> world, even the SourceHut you mentioned below, which is also operated,
> at least in part, as a commercial product. OTOH, Linux kernel [1] has
> already adopted GitHub as its development platform, which is also
> complete free and a classic example of successful free software.

When GNU software refers to "free", it is inevitably used to mean
"freedom".  In this case, it means the ability of a user to use a
network service without running proprietary software.

Furthermore, there is also the requirement that the flagship program of
the GNU project, naturally, must be hosted on a GNU project server,
which requires that the software running the service must itself be free
software.

> I can't say anything. Almost all Emacs developers and users are
> excellent programmers/scientists/engineers. But excellent people also
> have their own beliefs, quirks and their inner bottom line. Sometimes
> it may not be consistent with the prevailing trend, just like the
> existence of Emacs itself.

But Emacs doesn't exist to be consistent with a prevailing trend.  It
exists to better the GNU system.

> Technically speaking, I think there are so many guys in Emacs
> community have enough ability to do this.

There undoubtedly are, but none of them have stepped up to do the work.
Plus, things are cozy as they stand.

> [1] https://github.com/torvalds/linux

Does that count as full adoption? If so, so does this:
https://github.com/emacs-mirror/emacs

Cheers!

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

[Kévin Le Gouguec]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

>                                            OTOH, Linux kernel [1] has
> already adopted GitHub as its development platform, which is also
> complete free and a classic example of successful free software.
>
> [1] https://github.com/torvalds/linux

FTR: this is a read-only mirror.  As the helpful bot that answers every
pull request there says:

> Thanks for your contribution to the Linux kernel!

> Linux kernel development happens on mailing lists, rather than on
> GitHub - this GitHub repository is a read-only mirror that isn't used
> for accepting contributions. So that your change can become part of
> Linux, please email it to us as a patch.

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

[Hongyi Zhao]

On Sat, Sep 4, 2021 at 9:47 PM Kévin Le Gouguec
<kevin.legouguec@gmail.com> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >                                            OTOH, Linux kernel [1] has
> > already adopted GitHub as its development platform, which is also
> > complete free and a classic example of successful free software.
> >
> > [1] https://github.com/torvalds/linux
>
> FTR: this is a read-only mirror.  As the helpful bot that answers every
> pull request there says:
>
> > Thanks for your contribution to the Linux kernel!
>
> > Linux kernel development happens on mailing lists, rather than on
> > GitHub - this GitHub repository is a read-only mirror that isn't used
> > for accepting contributions. So that your change can become part of
> > Linux, please email it to us as a patch.

Thank you for pointing this out. But the KernelPRBot [1] also admits
the following:

Sending patches isn't quite as simple as sending a pull request, but
fortunately it is a well documented process.

[1] https://github.com/KernelPRBot

Best, Hongyi

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

[Ben Mezger]

I don't think a follow-up in this thread is necessary, as there is a
huge thread already in place concerning this discussion, but:

> OTOH, Linux kernel [1] has already adopted GitHub as its development
> platform, which is also complete free and a classic example of
> successful free software.

Not really, no. The Linux's Github repo is only a mirror of the
repository, however, no PR, discussion happen there, and those that do
happen, are ignored.

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> On Sat, Sep 4, 2021 at 7:24 PM Po Lu <luangruo@yahoo.com> wrote:
>>
>> > Nowadays, the large software projects often conduct the development on
>> > the workflow supplied by git  forges (GitHub, Bitbucket, GitLab,
>> > etc.). But it seems that Emacs is still developed directly on git, as
>> > described here [1], which makes maintaining GNU Emacs development a
>> > lot of extra work.
>>
>> GitHub, Bitbucket and GitLab require their users to run non-free
>> software, which already disqualifies them for the development of GNU
>> software.
>
> If so, I don't think there is such a complete free platform in the
> world, even the SourceHut you mentioned below, which is also operated,
> at least in part, as a commercial product. OTOH, Linux kernel [1] has
> already adopted GitHub as its development platform, which is also
> complete free and a classic example of successful free software.
>
>> There was recently a discussion (perhaps it is still in progress? I
>> don't know) about moving to SourceHut, but I don't think it's gone
>> anywhere.  The problem seems to be that the present system exists and
>> works, while nobody has sat down and completed the work required to
>> migrate to a new one.
>
> I can't say anything. Almost all Emacs developers and users are
> excellent programmers/scientists/engineers. But excellent people also
> have their own beliefs, quirks and their inner bottom line. Sometimes
> it may not be consistent with the prevailing trend, just like the
> existence of Emacs itself.
>
>> Would you like to volunteer? :D
>
> Technically speaking, I think there are so many guys in Emacs
> community have enough ability to do this.
>
> [1] https://github.com/torvalds/linux
>
> Best, Hongyi


--
Kind regards,
Met een vriendelijke groet,
Atenciosamente,

Ben Mezger

https://seds.nl
https://github.com/benmezger

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

[Philip Kaludercic]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> Sending patches isn't quite as simple as sending a pull request, but
> fortunately it is a well documented process.

It depends, I have certainly had times where sending a patch was easier
than preparing a pull request. One thing that was mentioned in the other
thread is that people are not used to patches on mailing
lists. Sourcehut and specifically git-send-email.io came up with the
clever idea of providing a testing list that nobody reads, just to see
how their messages will end up looking like. As long as you don't have
to worry that any small small mistake will have an army of greybeards
shouting at you for messing up, I think people are more accepting of a
different workflow (or that is at least my experience).

-- 
	Philip Kaludercic

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

[Hongyi Zhao]

On Sat, Sep 4, 2021 at 9:29 PM Po Lu <luangruo@yahoo.com> wrote:
> [...]
> But Emacs doesn't exist to be consistent with a prevailing trend.  It
> exists to better the GNU system.

It's only ever been a minuscule minority of the population who
work at the leading edge of human advance.

Best, Hongyi

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

[Po Lu]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> It's only ever been a minuscule minority of the population who
> work at the leading edge of human advance.

I'm not sure I understand what you're alluding to here.  Would you
please explain further? Thanks.

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

[Hongyi Zhao]

On Sun, Sep 5, 2021 at 11:16 AM Po Lu <luangruo@yahoo.com> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> > It's only ever been a minuscule minority of the population who
> > work at the leading edge of human advance.
>
> I'm not sure I understand what you're alluding to here.  Would you
> please explain further? Thanks.

Emacs may be the most ancient and powerful tool used by core/kernel
level developers in the world, who are only a small percentage of
developers. However, it is based on the results of these developments
that there are all kinds of unprecedented developments in the field of
Internet and supercomputer.

Best, Hongyi

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

[Po Lu]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> Emacs may be the most ancient and powerful tool used by core/kernel
> level developers in the world, who are only a small percentage of
> developers. However, it is based on the results of these developments
> that there are all kinds of unprecedented developments in the field of
> Internet and supercomputer.

I don't understand how, if this is true at all, this pertains to the
development system used by GNU Emacs?

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

[Hongyi Zhao]

On Sun, Sep 5, 2021 at 3:34 PM Po Lu <luangruo@yahoo.com> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> > Emacs may be the most ancient and powerful tool used by core/kernel
> > level developers in the world, who are only a small percentage of
> > developers. However, it is based on the results of these developments
> > that there are all kinds of unprecedented developments in the field of
> > Internet and supercomputer.
>
> I don't understand how, if this is true at all, this pertains to the
> development system used by GNU Emacs?

Is Emacs also used to develop itself? I just want to express the
following point of view: a few people did some original work that
ultimately influenced the course of world development. This is just my
own feeling, not necessarily of universal significance

Best, Hongyi

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

[Po Lu]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> Is Emacs also used to develop itself? I just want to express the
> following point of view: a few people did some original work that
> ultimately influenced the course of world development. This is just my
> own feeling, not necessarily of universal significance

To the best of my knowledge, yes, Emacs is the primary tool for Emacs
development.

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

[Max Nikulin]

On 04/09/2021 20:47, Kévin Le Gouguec wrote:
> Hongyi Zhao writes:
> 
>>                                             OTOH, Linux kernel [1] has
>> already adopted GitHub as its development platform, which is also
>> complete free and a classic example of successful free software.
>>
>> [1] https://github.com/torvalds/linux
> 
> FTR: this is a read-only mirror.  As the helpful bot that answers every
> pull request there says:
> 
>> Linux kernel development happens on mailing lists, rather than on
>> GitHub - this GitHub repository is a read-only mirror that isn't used
>> for accepting contributions. So that your change can become part of
>> Linux, please email it to us as a patch.

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:

Daniel Vetter. Why Github can't host the Linux Kernel Community. August 
8, 2017
https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

Though such reasons were not discussed in Microsoft's proposal to use 
"modern" approach for Linux development:

Relying on plain-text email is a 'barrier to entry' for kernel 
development, says Linux Foundation board member. Interview with Sarah 
Novotny. 2020-08-25
https://www.theregister.com/2020/08/25/linux_kernel_email/

These links are intended just to show that various project may have 
quite different reasons to resist development on github/gitlab despite 
some demand. I hope, it will not cause Microsoft & Linux flame here.

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

[Po Lu]

Max Nikulin <manikulin@gmail.com> 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.

Unlike the Linux kernel, however, the time spent by these experts
working on Emacs is much less than the time spent by experts working on
the Linux kernel, which, IMO, simply makes Emacs less suited to such a
work-flow.

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

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

[Dmitry Gutov]

On 08.09.2021 05:02, Po Lu wrote:
> 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.

Checkout the description of Linux's current workflow in this article: 
https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

It describes their practices, with many teams, corresponding 
repositories and complex interflow of patches.

Emacs development is nowhere near that scale.

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. 

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

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Thu, 09 Sep 2021 08:49:11 +1000
> 
> 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.

This is something for the active developers to decide.  And we have
made that decision: we are willing to switch to a platform which makes
it easier for occasional contributors to work with us.  We are just
looking for a platform that will fit our minimal requirements, which
is likely to require some changes in even the best of the platforms.

So let's not keep arguing about whether this kind of change in
supported workflows is justified: we already made the decision, and I
see no reason to reverse it, not yet anyway.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Emacs is not an operating system, and neither is Linux.
Emacs is a text editor with other features.
Linus is a kernel.

See https://gnu.org/gnu/linux-and-gnu.html and
https://gnu.org/gnu/gnu-linux-faq.html, plus the history in
https://gnu.org/gnu/the-gnu-project.html.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Max Nikulin]

On 10/09/2021 10:39, Richard Stallman wrote:
 >    > On 09/09/2021 00:34, Max Nikulin wrote:
> 
>    > > 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.
> 
> Emacs is not an operating system, and neither is Linux.

My apologizes. I had a hope the following:

 >    > More seriously, ...

was enough to show that I was kidding.

> Emacs is a text editor with other features.

Actually it is significantly more than just text editor and the joke was 
in support of "Emacs is a large project with many subsystems that 
stretch across a great amount of expertise domains." words by Po Lu.

People use Emacs as a mail user agent, a PDF viewer, even a window 
manager, etc. Sometimes it is just convenient, sometimes it is a way to 
minimize switching of UI context since there are conflicts between Emacs 
and many other applications in respect to actions in response to key and 
mouse events. Existing variety of Emacs features (including external 
packages) should not be disregarded.

Maybe my words on Linux kernel and Emacs development workflows were not 
clear enough. My opinion is the following:

- Development of Linux kernel is an interesting case for discussion
   on web UI vs. mail list workflow.
- Linux kernel development is email-based and rather successful,
   so it can be an argument that Emacs can continue using mail lists
   to propose and to discuss changes.
- 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.
   Scales of projects are rather different (large and huge).
- Web UIs have features such as dashboard with status of submitted
   patches, so it is nice that Eli clearly expressed that developers
   do not mind change (hopefully mostly by adding new features)
   of workflow.
- I had no aim to tell that GitHub/GitLab workflow is better for Emacs.
   Certainly comfortable way for main developers is more important.
   My point was that the case of Linux kernel is not a blocker for Emacs
   and nothing more.

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

This is a small thing, but:

On Thu, Sep 16, 2021 at 10:25 AM Max Nikulin <manikulin@gmail.com> 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.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1156 bytes --]

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.