unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Gitlab Migration
@ 2021-08-26 16:20 Daniel Fleischer
  2021-08-26 16:32 ` Eli Zaretskii
                   ` (6 more replies)
  0 siblings, 7 replies; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-26 16:20 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/html, Size: 4341 bytes --]

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
@ 2021-08-26 16:32 ` Eli Zaretskii
  2021-08-26 16:40   ` Dmitry Gutov
  2021-08-26 16:38 ` Lars Ingebrigtsen
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 16:32 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Thu, 26 Aug 2021 19:20:36 +0300
> 
> Possible issue:
> 
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website. Another approach is using the wonderful
>  Magit and Forge packages. Forge currently is lacking the discussions
>  feature but has a very good git + pull-requests + org-mode
>  integration abilities.
> 2 Changing processes, how people operate. Whether it's the technical
>  aspect of a pull-request approval vs. patch submission to the more
>  conceptual change of dealing with "issues" representing bugs, ideas,
>  feature requests or general discussions instead of mailing lists.
>  These changes shouldn't be too disruptive. However I do believe a
>  small price has to be paid in order to go from one local minima of
>  effort in a given practice to another, hopefully better local minima.
> 
> Does this describe well the current situation?
> What areas need attention in order to facilitate the change?

At the time, someone filed an issue with GitLab with a description of
the problems we discovered.  I'm quite sure the issue ID was posted
here.  I suggest to find that issue and read it (unless you already
did), because AFAIR there were several aspects to it, certainly more
than just 2 you mention.

Thanks.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
  2021-08-26 16:32 ` Eli Zaretskii
@ 2021-08-26 16:38 ` Lars Ingebrigtsen
  2021-08-26 17:24 ` Philip Kaludercic
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 16:38 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel

Daniel Fleischer <danflscr@gmail.com> writes:

> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab.

Yeah, that'd be great.  (But it's not really a VC system -- the version
control system will continue to be git.)

> Possible issue:
>
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website.

Yes, I think that's the biggest hurdle -- I think we really need that or
risk losing a number of our current contributors.  Can you interact with
Gitlab via a mail-only system?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:32 ` Eli Zaretskii
@ 2021-08-26 16:40   ` Dmitry Gutov
  2021-08-26 16:56     ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 16:40 UTC (permalink / raw)
  To: Eli Zaretskii, Daniel Fleischer; +Cc: emacs-devel

On 26.08.2021 19:32, Eli Zaretskii wrote:
>> From: Daniel Fleischer<danflscr@gmail.com>
>> Date: Thu, 26 Aug 2021 19:20:36 +0300
>>
>> Possible issue:
>>
>> 1 Being able to use Emacs for all these needs. One way is being able to
>>   interact with the VC system using emails, i.e. issues, features,
>>   discussions should have a nice and efficient email interface in
>>   addition to using a website. Another approach is using the wonderful
>>   Magit and Forge packages. Forge currently is lacking the discussions
>>   feature but has a very good git + pull-requests + org-mode
>>   integration abilities.
>> 2 Changing processes, how people operate. Whether it's the technical
>>   aspect of a pull-request approval vs. patch submission to the more
>>   conceptual change of dealing with "issues" representing bugs, ideas,
>>   feature requests or general discussions instead of mailing lists.
>>   These changes shouldn't be too disruptive. However I do believe a
>>   small price has to be paid in order to go from one local minima of
>>   effort in a given practice to another, hopefully better local minima.
>>
>> Does this describe well the current situation?
>> What areas need attention in order to facilitate the change?
> At the time, someone filed an issue with GitLab with a description of
> the problems we discovered.  I'm quite sure the issue ID was posted
> here.  I suggest to find that issue and read it (unless you already
> did), because AFAIR there were several aspects to it, certainly more
> than just 2 you mention.

https://gitlab.com/gitlab-org/gitlab/-/issues/28152

It's pretty daunting, I'd say.

And requires not only work on our side but also a number of improvements 
in Gitlab upstream (there are some linked discussions there on those 
sub-issues, but I'm assuming, best case, they are all currently waiting 
for volunteers).



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:40   ` Dmitry Gutov
@ 2021-08-26 16:56     ` Eli Zaretskii
  2021-08-26 19:27       ` Dmitry Gutov
  2021-08-26 19:38       ` dick
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 16:56 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: danflscr, emacs-devel

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 19:40:35 +0300
> 
> > At the time, someone filed an issue with GitLab with a description of
> > the problems we discovered.  I'm quite sure the issue ID was posted
> > here.  I suggest to find that issue and read it (unless you already
> > did), because AFAIR there were several aspects to it, certainly more
> > than just 2 you mention.
> 
> https://gitlab.com/gitlab-org/gitlab/-/issues/28152
> 
> It's pretty daunting, I'd say.
> 
> And requires not only work on our side but also a number of improvements 
> in Gitlab upstream (there are some linked discussions there on those 
> sub-issues, but I'm assuming, best case, they are all currently waiting 
> for volunteers).

We could prioritize the requirements, perhaps, and consider switching
after some critical mass of them is done.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
  2021-08-26 16:32 ` Eli Zaretskii
  2021-08-26 16:38 ` Lars Ingebrigtsen
@ 2021-08-26 17:24 ` Philip Kaludercic
  2021-08-26 17:52   ` Theodor Thornhill
                     ` (7 more replies)
  2021-08-26 18:51 ` Stefan Monnier
                   ` (3 subsequent siblings)
  6 siblings, 8 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-08-26 17:24 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel


Hi,

Daniel Fleischer <danflscr@gmail.com> writes:

> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab. I started reading the relevant threads and I'm not sure
> where the issue stands today. Let me recap the benefits:
>
> 1 The need for new people to join the community and help. Newer
>  (younger) people will be more familiar with the newer VC platforms
>  (github/lab and similar). These are not only developers but regular
>  users who want to report an issue (bug) or suggest a feature.

Shouldn't it be easier to send an email than create an account, navigate
some web UI and fill in some form? The same goes for
patches. Git{Lab,Hub} usually requires leaving the development context,
to prepare a patch online, that requires "forking", more navigation and
more fora. Just today I tried preparing a "pull request" on GitLab and
didn't manage to do so, because it insisted on merging the commit into
my own repository, no matter what I did. Just attaching a git patch
seems much easier.

>  Lowering the bar for participation is the key to growing Emacs and
>  the community.

I think that showing people that they biases against mailing list
development might be illegitimate would be a viable alternative.

> 2 Having the code + issues + discussions in the same place as opposed
>  to now, where the code and discussions (lists) are in 3 different
>  places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
>  modern VC system, one can jump easily between issues, discussions,
>  code commits back and forth easily as opposed to now, where if it's a
>  bug you can use its number to search lists and commits messages but
>  if it's a discussion, it's not "connected" to anything.

Correct me if I am wrong, but all the discussions are at least mirrored
on the mailing lists. Savannah is just for project management and the
GNU bug tracker uses the mailing list too. It is more uniform too, as
everything is just a mail-message, not part of a forcefully linearized
thread. Commenting on a issue, "pull request" or a patch is always just
responding to a message.

That being said, I wouldn't mind prettier web interface for the mailing
list (I think that the Guix project is doing well on that front).

> Possible issue:
>
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website. Another approach is using the wonderful
>  Magit and Forge packages. Forge currently is lacking the discussions
>  feature but has a very good git + pull-requests + org-mode
>  integration abilities.

I remember Sourceforge being suggested as an alternative to Gitlab, but
the software is currently still in a beta stage (AFAIR).

> 2 Changing processes, how people operate. Whether it's the technical
>  aspect of a pull-request approval vs. patch submission to the more
>  conceptual change of dealing with "issues" representing bugs, ideas,
>  feature requests or general discussions instead of mailing lists.
>  These changes shouldn't be too disruptive. However I do believe a
>  small price has to be paid in order to go from one local minima of
>  effort in a given practice to another, hopefully better local minima.
>
> Does this describe well the current situation?
> What areas need attention in order to facilitate the change?
>
> Thanks for any feedback.
>
> Daniel Fleischer
>

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
@ 2021-08-26 17:52   ` Theodor Thornhill
  2021-08-26 18:21     ` Philip Kaludercic
  2021-08-26 17:59   ` Lars Ingebrigtsen
                     ` (6 subsequent siblings)
  7 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-26 17:52 UTC (permalink / raw)
  To: emacs-devel, Philip Kaludercic, Daniel Fleischer



On 26 August 2021 19:24:07 CEST, Philip Kaludercic <philipk@posteo.net> wrote:
>
>
>I remember Sourceforge being suggested as an alternative to Gitlab, but
>the software is currently still in a beta stage (AFAIR).
>

Do you mean SourceHut or Sourceforge? SourceHut does have an explicit goal to support mailbased workflow, and supports an interface to it as well. It is pretty neat IMO. 


https://sr.ht/

--
Theodor Thornhill

>>
>



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
  2021-08-26 17:52   ` Theodor Thornhill
@ 2021-08-26 17:59   ` Lars Ingebrigtsen
  2021-08-26 18:42     ` Jim Porter
  2021-08-26 19:31     ` Dmitry Gutov
  2021-08-26 18:01   ` john muhl
                     ` (5 subsequent siblings)
  7 siblings, 2 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 17:59 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Daniel Fleischer, emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.

It seems like it should be easier to just send a patch, but feedback
we're getting shows that it's not for a number of developers.  Many
don't use mail at all for development, and all they're used to is the
GitLab/Hub way of doing it.

So it's easier for them -- it feels safe and familiar for them to do
development by clicking around in a web browser.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
  2021-08-26 17:52   ` Theodor Thornhill
  2021-08-26 17:59   ` Lars Ingebrigtsen
@ 2021-08-26 18:01   ` john muhl
  2021-08-26 19:08     ` Greg Farough
  2021-08-27 13:47     ` Daniel Martín
  2021-08-26 18:36   ` Clément Pit-Claudel
                     ` (4 subsequent siblings)
  7 siblings, 2 replies; 525+ messages in thread
From: john muhl @ 2021-08-26 18:01 UTC (permalink / raw)
  To: emacs-devel

On Thu, 2021-08-26 at 17:24 +0000, Philip Kaludercic wrote:
> 
> I remember Sourceforge being suggested as an alternative to Gitlab,

I think you mean sourcehut <https://sourcehut.org/> (free software)
not sourceforge <https://sourceforge.net/> (saas).

> but the software is currently still in a beta stage (AFAIR).

Pre-beta/alpha stage as of the latest update:
https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3CCDJYU3UHYS0I.3N2HFRMA6AIUB%40taiga%3E

GNU Ethical Repository Criteria related discussion:
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a79fifzl.fsf%40fsf.org%3E
https://lists.sr.ht/~sircmpwn/sr.ht-
discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:52   ` Theodor Thornhill
@ 2021-08-26 18:21     ` Philip Kaludercic
  0 siblings, 0 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-08-26 18:21 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: Daniel Fleischer, emacs-devel

Theodor Thornhill <theo@thornhill.no> writes:

> On 26 August 2021 19:24:07 CEST, Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>>I remember Sourceforge being suggested as an alternative to Gitlab, but
>>the software is currently still in a beta stage (AFAIR).
>>
>
> Do you mean SourceHut or Sourceforge? SourceHut does have an explicit goal to support mailbased workflow, and supports an interface to it as well. It is pretty neat IMO. 

Oops, sourcehut of course.

>
> https://sr.ht/
>
> --
> Theodor Thornhill
>
>>>
>>

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
                     ` (2 preceding siblings ...)
  2021-08-26 18:01   ` john muhl
@ 2021-08-26 18:36   ` Clément Pit-Claudel
  2021-08-26 19:04     ` Eli Zaretskii
  2021-08-26 21:24     ` Arthur Miller
  2021-08-26 23:52   ` Tim Cross
                     ` (3 subsequent siblings)
  7 siblings, 2 replies; 525+ messages in thread
From: Clément Pit-Claudel @ 2021-08-26 18:36 UTC (permalink / raw)
  To: emacs-devel

On 8/26/21 1:24 PM, Philip Kaludercic wrote:
> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form?

I don't have strong opinions on mailing lists vs other approaches; but: no, not necessarily.

- Unlike email, a webform allows mistakes to be fixed easily (messages can be edited after being posted).  A mailing list does not allow this, so for newcomers the fear of "doing something wrong" is high.  Many projects have an issue reporting template now, and that can be nice.

  (Yes, emacs has M-x report-emacs-bug, but no, I haven't set up my Emacs to send email yet, despite using Emacs for the last ten years).

- Common actions can be mapped to buttons and dropdowns, making them more easily discoverable. I don't interact with debbugs often enough to remember the commands, so I need to look them up every time I want to close a bug, tag an issue, etc.  In practice, I mostly leave these tasks to other volunteers.  With a web UI, I can apply tags from a list of known tags, close issues, mark duplicates, subscribe to an issue, etc. just by clicking my way around.  I can also trivially CC someone in a discussion (this is not easy with debbugs: you need to set up a custom header in your message, and mistakes can't be fixed by editing the original message).  It may be less efficient (although email isn't exactly fast), but it's very discoverable. 

- State tracking can be easier.  The Gitlab UI has, at all times, the latest version of a patchset.  On the emacs mailing list, maintainers regularly request a user to resent the latest version of a patchset, because changes can become hard to follow otherwise.  

- It requires less expertise with git and the patching workflow.  Committing to "one branch per patch" means that contributors don't need to know how to prepare and send or apply patches.  It also means that maintainers (or bots!) can push fixes directly, instead of requesting them.  For example recently I opened a pull request for a Python project I had never contributed to, and an automated system promptly pushed an additional commit to the branch to reformat my code using the project's preferred style.  With Emacs patches we typically ask the author to fix issues that are spotted by hand by a reviewer. 

- Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?

I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:59   ` Lars Ingebrigtsen
@ 2021-08-26 18:42     ` Jim Porter
  2021-08-26 19:09       ` Eli Zaretskii
  2021-08-26 19:31     ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Jim Porter @ 2021-08-26 18:42 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Philip Kaludercic; +Cc: Daniel Fleischer, emacs-devel

On 8/26/2021 10:59 AM, Lars Ingebrigtsen wrote:
> It seems like it should be easier to just send a patch, but feedback
> we're getting shows that it's not for a number of developers.  Many
> don't use mail at all for development, and all they're used to is the
> GitLab/Hub way of doing it.

I'm pretty new contributing to Emacs, and so I can definitely understand 
the feeling of intimidation about using a mailing list-based workflow 
for contributions. However, once I actually tried it, it turned out to 
be very similar as a contributor (I don't know if I'd want to *maintain* 
a project using a mailing list workflow, but that's not my job, so it's 
not a problem for me).

One issue, however, is that the documentation for sending patches[1], 
while very thorough, doesn't make things easy to understand for someone 
familiar with a pull request workflow. While all the advice in the 
documentation is useful, a lot of it is stuff that anyone who's sent a 
PR before (hopefully) already knows, such as, "Don’t mix together 
changes made for different reasons. Send them individually."

After resolving to read the documentation thoroughly, I realized I only 
really needed a few short bits of advice:

1) The bug tracker is at https://debbugs.gnu.org
2) To submit a patch:
    a) Clone the Emacs git repo
    b) Make a branch and add some commits (as usual for the PR workflow)
    c) Run `git format-patch master`
    d) Compose an email to bug-gnu-emacs@ with the files in (c) attached
3) Commit messages have a special format (but you can just imitate what 
you see in prior commits)

Almost everything else is either common advice for contributing to any 
project, or something maintainers can address after a patch is submitted 
(e.g. copyright assignment). While I don't think the existing 
documentation should be removed, having a "quick-start intro" for people 
already familiar with the PR workflow would probably go a long way 
towards making new contributors feel less intimidated.

If the above sounds reasonable, I can work on a patch to the docs once 
my copyright paperwork is updated (or someone else can update them 
instead; I don't have a preference). It might even be helpful to add a 
"Contributing" section to the main Emacs homepage[2] with a short 
version of what's already in the full documentation.

- Jim

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



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
                   ` (2 preceding siblings ...)
  2021-08-26 17:24 ` Philip Kaludercic
@ 2021-08-26 18:51 ` Stefan Monnier
  2021-08-26 19:13   ` john muhl
  2021-08-28  3:03   ` Richard Stallman
  2021-08-27  0:37 ` Po Lu
                   ` (2 subsequent siblings)
  6 siblings, 2 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-26 18:51 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel

> Possible issue:

You forgot another one: we want the code to be hosted on machines under
the control of the GNU project.  The last I heard from this is that some
software was considered and there was a web page summarizing the status,
but that was maybe 2 years ago and I can't find that page any more now
have I heard anything again.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:36   ` Clément Pit-Claudel
@ 2021-08-26 19:04     ` Eli Zaretskii
  2021-08-26 19:26       ` Lars Ingebrigtsen
                         ` (3 more replies)
  2021-08-26 21:24     ` Arthur Miller
  1 sibling, 4 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 19:04 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 26 Aug 2021 14:36:17 -0400
> 
> - It requires less expertise with git and the patching workflow.  Committing to "one branch per patch" means that contributors don't need to know how to prepare and send or apply patches.  It also means that maintainers (or bots!) can push fixes directly, instead of requesting them.  For example recently I opened a pull request for a Python project I had never contributed to, and an automated system promptly pushed an additional commit to the branch to reformat my code using the project's preferred style.  With Emacs patches we typically ask the author to fix issues that are spotted by hand by a reviewer. 

It's actually the other way around, at least in some cases.  With
patches that are emailed to me, I can fix some simple issues, such as
commit log messages or simple typos, myself, before applying.  With
merging via Web UI, I need to push another commit, which is a waste,
and also breaks what should have been a single commit into several
ones.  So with Web UI, I expect _more_ requests to contributors to get
their act together, where automated fixups are impossible, because
there's little I can do myself.

> - Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?

I think you see problems where there are none.  If you have an email
message that belongs to a bug, reply to it; otherwise simply write to
the bug address.  admin/notes/bugtracker explains this within its
first dozen of lines.

And it isn't like GitLab and similar platforms don't have similar
issues: e.g., I don't know to this day how to reply to a specific
comment there (as opposed to the last one), nor how to cite portions
of the comment to which I respond.  And that's _after_ I overcome the
shock of not being able to use sophisticated editing commands and
spell-checking.

> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.

I realize that some people who want to contribute don't like emacs or
are intimidated by it.  That's an important reason to provide the UI
to which they are more accustomed.  But let's not exaggerate the
advantages of these platforms for the Emacs developers: though some
advantages exist, they are not that significant, at least IMO, and
there are disadvantages (described in the GitLab issue).

IOW, the most important reason for this move is to be more welcoming
to casual contributors, not to make the job much easier for the
maintainers.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:01   ` john muhl
@ 2021-08-26 19:08     ` Greg Farough
  2021-08-26 19:21       ` Stefan Monnier
  2021-08-27 13:47     ` Daniel Martín
  1 sibling, 1 reply; 525+ messages in thread
From: Greg Farough @ 2021-08-26 19:08 UTC (permalink / raw)
  To: emacs-devel

On Thu, Aug 26 2021, john muhl <email@johnmuhl.mx> wrote:

> On Thu, 2021-08-26 at 17:24 +0000, Philip Kaludercic wrote:
>> 
>> I remember Sourceforge being suggested as an alternative to Gitlab,
>
> I think you mean sourcehut <https://sourcehut.org/> (free software)
> not sourceforge <https://sourceforge.net/> (saas).
>
>> but the software is currently still in a beta stage (AFAIR).
>
> Pre-beta/alpha stage as of the latest update:
> https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3CCDJYU3UHYS0I.3N2HFRMA6AIUB%40taiga%3E
>
> GNU Ethical Repository Criteria related discussion:
> https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a79fifzl.fsf%40fsf.org%3E
> https://lists.sr.ht/~sircmpwn/sr.ht-
> discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E

On that note, I should mention that GNU's ethical repo working group
is about to update GitLab's rating to an F[1]. I would not consider it
an acceptable place to host a GNU program.

Once the changes are made to the ethical repo page, Sourcehut will
have a B[2]. Meaning, as per the criteria[3], that it is acceptable to
host a GNU program.

-g

[1]:
https://lists.defectivebydesign.org/archive/html/repo-criteria-discuss/2021-06/msg00035.html
[2]:
https://lists.defectivebydesign.org/archive/html/repo-criteria-discuss/2021-06/msg00036.html
[3]: https://www.gnu.org/software/repo-criteria.html

-- 
"We carry a new world here, in our hearts. That world is growing in
this minute."




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:42     ` Jim Porter
@ 2021-08-26 19:09       ` Eli Zaretskii
  0 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 19:09 UTC (permalink / raw)
  To: Jim Porter; +Cc: larsi, danflscr, philipk, emacs-devel

> From: Jim Porter <jporterbugs@gmail.com>
> Date: Thu, 26 Aug 2021 11:42:08 -0700
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> After resolving to read the documentation thoroughly, I realized I only 
> really needed a few short bits of advice:
> 
> 1) The bug tracker is at https://debbugs.gnu.org
> 2) To submit a patch:
>     a) Clone the Emacs git repo
>     b) Make a branch and add some commits (as usual for the PR workflow)
>     c) Run `git format-patch master`
>     d) Compose an email to bug-gnu-emacs@ with the files in (c) attached
> 3) Commit messages have a special format (but you can just imitate what 
> you see in prior commits)
> 
> Almost everything else is either common advice for contributing to any 
> project, or something maintainers can address after a patch is submitted 
> (e.g. copyright assignment). While I don't think the existing 
> documentation should be removed, having a "quick-start intro" for people 
> already familiar with the PR workflow would probably go a long way 
> towards making new contributors feel less intimidated.
> 
> If the above sounds reasonable, I can work on a patch to the docs once 
> my copyright paperwork is updated (or someone else can update them 
> instead; I don't have a preference). It might even be helpful to add a 
> "Contributing" section to the main Emacs homepage[2] with a short 
> version of what's already in the full documentation.

Feel free to work on this, and let's talk after you actually have a
patch.

However, please note that people vary in their prior background, and
what is clear to someone who has experience with PRs and/or some
knowledge of Git, may be less known to others.  Thus, making this kind
of docs both concise and detailed enough is a problem without trivial
solutions, because that document is written for everyone, not just for
PR veterans.

But don't let me discourage you from trying ;-)



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:51 ` Stefan Monnier
@ 2021-08-26 19:13   ` john muhl
  2021-08-27  6:50     ` Daniel Fleischer
  2021-08-28  3:03   ` Richard Stallman
  1 sibling, 1 reply; 525+ messages in thread
From: john muhl @ 2021-08-26 19:13 UTC (permalink / raw)
  To: emacs-devel

On Thu, 2021-08-26 at 14:51 -0400, Stefan Monnier wrote:
> 
> The last I heard from this is that some software was considered and
> there was a web page summarizing the status, but that was maybe 2
> years ago and I can't find that page any more

maybe one on these:
https://libreplanet.org/wiki/FSF_2020_forge_evaluation
https://www.gnu.org/software/repo-criteria-evaluation.html




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:08     ` Greg Farough
@ 2021-08-26 19:21       ` Stefan Monnier
  0 siblings, 0 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-26 19:21 UTC (permalink / raw)
  To: Greg Farough; +Cc: emacs-devel

> On that note, I should mention that GNU's ethical repo working group
> is about to update GitLab's rating to an F[1]. I would not consider it
> an acceptable place to host a GNU program.

Side note: this working group is focused on evaluating hosting services,
rather than evaluating software to use for such hosting (which you
could use to self-host).  E.g. it evaluates the gitlab.com service
rather than the Gitlab software.

AFAIK the intention for Emacs is to host it on GNU-managed servers, so
it would be self-hosting in this sense and not using any particular
existing service provider.

The two are related but somewhat different.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:04     ` Eli Zaretskii
@ 2021-08-26 19:26       ` Lars Ingebrigtsen
  2021-08-26 21:52         ` Stefan Monnier
  2021-08-26 19:37       ` Dmitry Gutov
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 19:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Clément Pit-Claudel, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> It's actually the other way around, at least in some cases.  With
> patches that are emailed to me, I can fix some simple issues, such as
> commit log messages or simple typos, myself, before applying.

Indeed.  But I expect that whatever we end up with, we (that is, the
Emacs maintainers) won't have to click around, and won't have to
actually merge anything directly.  That is, I expect to have a command
in Emacs that says "get that pull request as a patch, apply it, and
don't commit it".  So that we can fix stuff up before committing -- as
before.

(I know, I can hear gasps of outrage from git fundamentalists already.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:56     ` Eli Zaretskii
@ 2021-08-26 19:27       ` Dmitry Gutov
  2021-08-26 19:33         ` Eli Zaretskii
  2021-08-27 22:50         ` Yuchen Pei
  2021-08-26 19:38       ` dick
  1 sibling, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 19:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: danflscr, emacs-devel

On 26.08.2021 19:56, Eli Zaretskii wrote:
> We could prioritize the requirements, perhaps, and consider switching
> after some critical mass of them is done.

Sounds good.

The two "external" items (reCAPTCHA and LibreJS) might be hard 
requirements from RMS, though.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:59   ` Lars Ingebrigtsen
  2021-08-26 18:42     ` Jim Porter
@ 2021-08-26 19:31     ` Dmitry Gutov
  2021-08-26 19:41       ` Eli Zaretskii
                         ` (2 more replies)
  1 sibling, 3 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 19:31 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Philip Kaludercic; +Cc: Daniel Fleischer, emacs-devel

On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
> Many
> don't use mail at all for development, and all they're used to is the
> GitLab/Hub way of doing it.

Email is used by virtually everyone (for example, to receive 
notifications about others' actions or messages), what's "unusual" for 
many is sending patches over email. Or inlining them in comments/messages.

> So it's easier for them -- it feels safe and familiar for them to do
> development by clicking around in a web browser.

We also have a bunch of formal rules for submissions which tend to seem 
intimidating. A CI with an automated checker running against all PRs can 
alleviate that problem.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:27       ` Dmitry Gutov
@ 2021-08-26 19:33         ` Eli Zaretskii
  2021-08-27 22:50         ` Yuchen Pei
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 19:33 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: danflscr, emacs-devel

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 22:27:35 +0300
> Cc: danflscr@gmail.com, emacs-devel@gnu.org
> 
> On 26.08.2021 19:56, Eli Zaretskii wrote:
> > We could prioritize the requirements, perhaps, and consider switching
> > after some critical mass of them is done.
> 
> Sounds good.
> 
> The two "external" items (reCAPTCHA and LibreJS) might be hard 
> requirements from RMS, though.

If we host it on Savannah, that will be resolved regardless.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:04     ` Eli Zaretskii
  2021-08-26 19:26       ` Lars Ingebrigtsen
@ 2021-08-26 19:37       ` Dmitry Gutov
  2021-08-26 19:44         ` Eli Zaretskii
                           ` (2 more replies)
  2021-08-26 20:09       ` Clément Pit-Claudel
  2021-08-27  0:38       ` Tim Cross
  3 siblings, 3 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 19:37 UTC (permalink / raw)
  To: Eli Zaretskii, Clément Pit-Claudel; +Cc: emacs-devel

On 26.08.2021 22:04, Eli Zaretskii wrote:
> If you have an email
> message that belongs to a bug, reply to it; otherwise simply write to
> the bug address.

...and cut off all prior participants from the discussions. Except those 
who are subscribed to the mailing list, of course.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:56     ` Eli Zaretskii
  2021-08-26 19:27       ` Dmitry Gutov
@ 2021-08-26 19:38       ` dick
  2021-08-26 19:51         ` Eli Zaretskii
                           ` (2 more replies)
  1 sibling, 3 replies; 525+ messages in thread
From: dick @ 2021-08-26 19:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, danflscr, Dmitry Gutov

* Newcomer suggests PR-based workflow citing youth.  Check.

* Veterans chime in, citing the obvious reasons-for and the
political reasons-against.  Check.

* EZ cites his *sui generis* argument that a web-based workflow is actually
*more* work than mailing patches around.  Check.

* Someone announces his intention to begin the necessary work.  Check.

* Someone remarks how discussion on emacs-devel repeats itself.  Now checked.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:31     ` Dmitry Gutov
@ 2021-08-26 19:41       ` Eli Zaretskii
  2021-08-26 20:12         ` Dmitry Gutov
  2021-08-27  0:40       ` Po Lu
  2021-08-27  1:01       ` Tim Cross
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 19:41 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: larsi, danflscr, philipk, emacs-devel

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 22:31:45 +0300
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
> > Many
> > don't use mail at all for development, and all they're used to is the
> > GitLab/Hub way of doing it.
> 
> Email is used by virtually everyone (for example, to receive 
> notifications about others' actions or messages), what's "unusual" for 
> many is sending patches over email. Or inlining them in comments/messages.

No, Lars is right: I've heard quite a lot of people saying that they
feel uneasy to write email messages.

> > So it's easier for them -- it feels safe and familiar for them to do
> > development by clicking around in a web browser.
> 
> We also have a bunch of formal rules for submissions which tend to seem 
> intimidating. A CI with an automated checker running against all PRs can 
> alleviate that problem.

Automation can alleviate only some of the violations, a minority IME.
For example, there's no automation known to me that can fix the commit
log entry format.

But anyway, what prevents us from having those same checkers running
on our machines as part of "git am"?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:37       ` Dmitry Gutov
@ 2021-08-26 19:44         ` Eli Zaretskii
  2021-08-26 20:05           ` Dmitry Gutov
  2021-09-02 15:30           ` Daniel Brooks
  2021-08-26 21:55         ` Stefan Monnier
  2021-08-27  6:00         ` tomas
  2 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 19:44 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: cpitclaudel, emacs-devel

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 22:37:32 +0300
> 
> On 26.08.2021 22:04, Eli Zaretskii wrote:
> > If you have an email
> > message that belongs to a bug, reply to it; otherwise simply write to
> > the bug address.
> 
> ...and cut off all prior participants from the discussions. Except those 
> who are subscribed to the mailing list, of course.

Way better than Github and its ilk, where I actually need to point my
browser to the issue to see the comments.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:38       ` dick
@ 2021-08-26 19:51         ` Eli Zaretskii
  2021-08-27  6:26         ` tomas
  2021-09-02 11:06         ` Alexander Adolf
  2 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-26 19:51 UTC (permalink / raw)
  To: dick; +Cc: dgutov, danflscr, emacs-devel

> From: dick <dick.r.chiang@gmail.com>
> Date: Thu, 26 Aug 2021 15:38:44 -0400
> Cc: emacs-devel@gnu.org, danflscr@gmail.com, Dmitry Gutov <dgutov@yandex.ru>
> 
> * Newcomer suggests PR-based workflow citing youth.  Check.
> 
> * Veterans chime in, citing the obvious reasons-for and the
> political reasons-against.  Check.
> 
> * EZ cites his *sui generis* argument that a web-based workflow is actually
> *more* work than mailing patches around.  Check.
> 
> * Someone announces his intention to begin the necessary work.  Check.
> 
> * Someone remarks how discussion on emacs-devel repeats itself.  Now checked.

What's the alternative? tell that "newcomer" we've been there and
please go away?  That's unkind and unbecoming.

Besides, there's always hope that this time someone will actually do
the job.  It did happen in the past.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:44         ` Eli Zaretskii
@ 2021-08-26 20:05           ` Dmitry Gutov
  2021-09-02 15:30           ` Daniel Brooks
  1 sibling, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 20:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: cpitclaudel, emacs-devel

On 26.08.2021 22:44, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Thu, 26 Aug 2021 22:37:32 +0300
>>
>> On 26.08.2021 22:04, Eli Zaretskii wrote:
>>> If you have an email
>>> message that belongs to a bug, reply to it; otherwise simply write to
>>> the bug address.
>>
>> ...and cut off all prior participants from the discussions. Except those
>> who are subscribed to the mailing list, of course.
> 
> Way better than Github and its ilk, where I actually need to point my
> browser to the issue to see the comments.

One is a social/collaborative matter, and another is a matter of 
personal convenience, which varies by person.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:04     ` Eli Zaretskii
  2021-08-26 19:26       ` Lars Ingebrigtsen
  2021-08-26 19:37       ` Dmitry Gutov
@ 2021-08-26 20:09       ` Clément Pit-Claudel
  2021-08-27  5:51         ` Eli Zaretskii
  2021-08-27  0:38       ` Tim Cross
  3 siblings, 1 reply; 525+ messages in thread
From: Clément Pit-Claudel @ 2021-08-26 20:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On 8/26/21 3:04 PM, Eli Zaretskii wrote:
> It's actually the other way around, at least in some cases.  With
> patches that are emailed to me, I can fix some simple issues, such as
> commit log messages or simple typos, myself, before applying.  With
> merging via Web UI, I need to push another commit, which is a waste,
> and also breaks what should have been a single commit into several
> ones.  So with Web UI, I expect _more_ requests to contributors to get
> their act together, where automated fixups are impossible, because
> there's little I can do myself.

Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?

>> - Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?
> 
> I think you see problems where there are none.  If you have an email
> message that belongs to a bug, reply to it; otherwise simply write to
> the bug address.  admin/notes/bugtracker explains this within its
> first dozen of lines.

This is in line with what I wrote above: there is a process that is specific to Emacs, and it requires reading a document that is specific to Emacs to get it right (and you have to find that document).

It's not that bad, really; just not super discoverable. 

> And it isn't like GitLab and similar platforms don't have similar
> issues

Oh, I agree (see my next sentence ^^).

>> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.
> 
> I realize that some people who want to contribute don't like emacs or
> are intimidated by it. 

I would be surprised if anyone who wants to contribute patches to Emacs doesn't like Emacs.  Maybe I'm misunderstanding what you're saying.

> That's an important reason to provide the UI
> to which they are more accustomed.  But let's not exaggerate the
> advantages of these platforms for the Emacs developers: though some
> advantages exist, they are not that significant, at least IMO, and
> there are disadvantages (described in the GitLab issue).

And yet few of the packages hosted on MELPA — even those that don't get many external contributions — are developed using mailing lists (not sure about GNU ELPA).  That might suggest that even Emacs veterans see value in these online systems (?)

But really, I don't know about this part.  All I was responding to is a comment about emailing patches being easier than web forms for newcomers, and about a need to fix misconceptions about email.

> IOW, the most important reason for this move is to be more welcoming
> to casual contributors, not to make the job much easier for the
> maintainers.

That's fair (but the maintainers are doing an incredible job today, so it would be terrible to make your job harder).  This was also the reason that the Gnome and KDE folks cited when they moved to Gitlab (in 2018 and 2020, respectively; https://about.gitlab.com/blog/2018/05/31/welcome-gnome-to-gitlab/ and https://about.gitlab.com/blog/2020/06/29/welcome-kde/).

FWIW, this was the issue that KDE was using to track requirements for their move https://gitlab.com/gitlab-org/gitlab/-/issues/24900 

There isn't much data on whether Gnome moving to gitlab has helped with contributions, unfortunately.






^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:41       ` Eli Zaretskii
@ 2021-08-26 20:12         ` Dmitry Gutov
  2021-08-26 20:51           ` Arthur Miller
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 20:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, danflscr, philipk, emacs-devel

On 26.08.2021 22:41, Eli Zaretskii wrote:
>> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>>> Many
>>> don't use mail at all for development, and all they're used to is the
>>> GitLab/Hub way of doing it.
>>
>> Email is used by virtually everyone (for example, to receive
>> notifications about others' actions or messages), what's "unusual" for
>> many is sending patches over email. Or inlining them in comments/messages.
> 
> No, Lars is right: I've heard quite a lot of people saying that they
> feel uneasy to write email messages.

While there are as many habits as there are people, perhaps we should 
interpret it more like "write a first email message", to a particular 
mailing list.

There is a whole list of worries a polite and careful person can 
associate with that.

>>> So it's easier for them -- it feels safe and familiar for them to do
>>> development by clicking around in a web browser.
>>
>> We also have a bunch of formal rules for submissions which tend to seem
>> intimidating. A CI with an automated checker running against all PRs can
>> alleviate that problem.
> 
> Automation can alleviate only some of the violations, a minority IME.
> For example, there's no automation known to me that can fix the commit
> log entry format.
> 
> But anyway, what prevents us from having those same checkers running
> on our machines as part of "git am"?

The point is, someone who has never contributed before can more easily 
see all bugs/PRs/discussions from the outside, and when they file a PR, 
see the checks succeed or fail (with specific complaints and 
recommendations) without having to involve a live person.

The ability to avoid bothering anyone directly (and risk a negative 
reception) can help avoid some of the worries.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 20:12         ` Dmitry Gutov
@ 2021-08-26 20:51           ` Arthur Miller
  2021-08-26 21:13             ` Dmitry Gutov
                               ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-26 20:51 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, Eli Zaretskii, danflscr, larsi, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 22:41, Eli Zaretskii wrote:
>>> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>>>> Many
>>>> don't use mail at all for development, and all they're used to is the
>>>> GitLab/Hub way of doing it.
>>>
>>> Email is used by virtually everyone (for example, to receive
>>> notifications about others' actions or messages), what's "unusual" for
>>> many is sending patches over email. Or inlining them in comments/messages.
>> No, Lars is right: I've heard quite a lot of people saying that they
>> feel uneasy to write email messages.
>
> While there are as many habits as there are people, perhaps we should interpret
> it more like "write a first email message", to a particular mailing list.
>
> There is a whole list of worries a polite and careful person can associate with
> that.
>
>>>> So it's easier for them -- it feels safe and familiar for them to do
>>>> development by clicking around in a web browser.
>>>
>>> We also have a bunch of formal rules for submissions which tend to seem
>>> intimidating. A CI with an automated checker running against all PRs can
>>> alleviate that problem.
>> Automation can alleviate only some of the violations, a minority IME.
>> For example, there's no automation known to me that can fix the commit
>> log entry format.
>> But anyway, what prevents us from having those same checkers running
>> on our machines as part of "git am"?
>
> The point is, someone who has never contributed before can more easily see all
> bugs/PRs/discussions from the outside, and when they file a PR, see the checks
> succeed or fail (with specific complaints and recommendations) without having to
> involve a live person.
Hmm, some projects have thousands of issues, some remove solved issues. I am not
sure it is so easily discoverable. Also I see a lot of comments on gh advising
users to first search for the issue before posting, which makes me thing that
people are not so good to "look first" if issue is already solved.

> The ability to avoid bothering anyone directly (and risk a negative reception)
> can help avoid some of the worries.

Maybe Emacs project should be better at informing users about Emacs bug tracker:

https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

and this one:

https://debbugs.gnu.org/

and debbugs package for browsing bugs directly from Emacs?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 20:51           ` Arthur Miller
@ 2021-08-26 21:13             ` Dmitry Gutov
  2021-08-26 22:05               ` Arthur Miller
  2021-08-26 21:41             ` [External] : " Drew Adams
  2021-08-27  6:09             ` Eli Zaretskii
  2 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-26 21:13 UTC (permalink / raw)
  To: Arthur Miller; +Cc: philipk, Eli Zaretskii, danflscr, larsi, emacs-devel

On 26.08.2021 23:51, Arthur Miller wrote:

>> The point is, someone who has never contributed before can more easily see all
>> bugs/PRs/discussions from the outside, and when they file a PR, see the checks
>> succeed or fail (with specific complaints and recommendations) without having to
>> involve a live person.
> Hmm, some projects have thousands of issues, some remove solved issues. I am not
> sure it is so easily discoverable. Also I see a lot of comments on gh advising
> users to first search for the issue before posting, which makes me thing that
> people are not so good to "look first" if issue is already solved.

I didn't mean to say it's perfect, just more manageable.

And, like you say, a lot of users are already "trained" to look for 
prior discussions, prior issues, etc. This is harder to do with the 
email-based workflow.

We see people on Emacs Help asking similar questions over and over.

>> The ability to avoid bothering anyone directly (and risk a negative reception)
>> can help avoid some of the worries.
> 
> Maybe Emacs project should be better at informing users about Emacs bug tracker:
> 
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
> 
> and this one:
> 
> https://debbugs.gnu.org/
> 
> and debbugs package for browsing bugs directly from Emacs?

They should be informed, yes, but our antiquated bug tracker is the main 
technical weak point of the project. Some of the previous messages which 
referred to difficulties in email-based workflow were actually about 
"email-based Debbugs workflow".



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:36   ` Clément Pit-Claudel
  2021-08-26 19:04     ` Eli Zaretskii
@ 2021-08-26 21:24     ` Arthur Miller
  1 sibling, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-26 21:24 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 8/26/21 1:24 PM, Philip Kaludercic wrote:
>> Shouldn't it be easier to send an email than create an account, navigate
>> some web UI and fill in some form?
>
> I don't have strong opinions on mailing lists vs other approaches; but: no, not necessarily.
>
> - Unlike email, a webform allows mistakes to be fixed easily (messages can be
> edited after being posted).  A mailing list does not allow this, so for
> newcomers the fear of "doing something wrong" is high.  Many projects have an
> issue reporting template now, and that can be nice.
I am an expert in having fingers faster than my brain. I found people here being
quite resonable when I send a second mail to correct my misstake.

You are a point there, it is easier to go back and fix errors, but that is about
the only one. I don't think that is so big deal to be a showstopper.

>   (Yes, emacs has M-x report-emacs-bug, but no, I haven't set up my Emacs to send email yet, despite using Emacs for the last ten years).
>
> - Common actions can be mapped to buttons and dropdowns, making them more easily
> discoverable. I don't interact with debbugs often enough to remember the
> commands, so I need to look them up every time I want to close a bug, tag an
> issue, etc.  In practice, I mostly leave these tasks to other volunteers.  With
> a web UI, I can apply tags from a list of known tags, close issues, mark
> duplicates, subscribe to an issue, etc. just by clicking my way around.  I can
> also trivially CC someone in a discussion (this is not easy with debbugs: you
> need to set up a custom header in your message, and mistakes can't be fixed by
> editing the original message).  It may be less efficient (although email isn't
> exactly fast), but it's very discoverable.
So you ask for a context menu for debbugs, that could be done?

> - State tracking can be easier.  The Gitlab UI has, at all times, the latest
> version of a patchset.  On the emacs mailing list, maintainers regularly request
> a user to resent the latest version of a patchset, because changes can become
> hard to follow otherwise.
>
> - It requires less expertise with git and the patching workflow.  Committing to
> "one branch per patch" means that contributors don't need to know how to
> prepare

That was something I had a thoughts about. Couldn't we have a command that
automate this, somethign like M-x create-patch-request. That could automatically
create a patch between current branch and master, and send it away, maybe prompt
user for an additional message.

>                             It also means that maintainers (or bots!) can push
> fixes directly, instead of requesting them.  For example recently I opened a
> pull request for a Python project I had never contributed to, and an automated
> system promptly pushed an additional commit to the branch to reformat my code
> using the project's preferred style.
Yes, but those things work only with things that are easily automated, such as
wha tyou mention, formatting the code. That can be automated with Emacs as well,
and I don't see reason why the patch author can't use Emacs formatting when
writing Emacs patch. I personally dislike gnu coding style, it is probably the
ugliest and most unreadable coding style I have ever seen, but how much pain
does it cause me to use it occasionally? Not much. I can live with that when I
work with Emacs sources.

> - Responding to old bugs is easier.  With a mailing list, it's no necessarily
> clear what the process is.  Should I send a new message to the bug address? Or
> does it need the right response headers?  In that case should I download the
> mbox first and import it into my email client?
>
> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.

You are correct, but it is not particulary easy to use web interfaces en massé
either. I mean, people will clone repo to local disk anyway and code patch in
Emacs. Git can auto create patch. If one setups email account in Emacs, it is a
few clicks away to send patch to mailing list. It is more work to update your
repo on your gitlab account, than click on some button and fill some form to
send a PR.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-26 20:51           ` Arthur Miller
  2021-08-26 21:13             ` Dmitry Gutov
@ 2021-08-26 21:41             ` Drew Adams
  2021-08-26 21:52               ` Arthur Miller
                                 ` (2 more replies)
  2021-08-27  6:09             ` Eli Zaretskii
  2 siblings, 3 replies; 525+ messages in thread
From: Drew Adams @ 2021-08-26 21:41 UTC (permalink / raw)
  To: Arthur Miller, Dmitry Gutov
  Cc: larsi, philipk, danflscr, Eli Zaretskii, emacs-devel

> Maybe Emacs project should be better at informing users 
> about Emacs bug tracker: ... and this one: ... and
> debbugs package for browsing bugs directly from Emacs?

(Apologies for not really following this thread.)

1. It might not help with the general process of tracking
or searching bugs, but we do have a `Help' menu item for
submitting a bug report: `Send Bug Report'.  That should
be an easy entry, in principle.

Of course that just invokes `report-emacs-bug'.  Maybe
the `report-emacs-bug' interaction scares some users and
could be made less scary (dunno).

3. Something else that might help a bit is to include,
in each mail sent to a bug thread, a debbugs.gnu.org 
link to that post.

4. And yes, a web interface (at debbugs.gnu.org or not)
that lets you not only view, but also reply to, posts
would be good.

5. And debbugs.gnu.org search sucks.  Or at least I suck
at trying to find anything using it.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:26       ` Lars Ingebrigtsen
@ 2021-08-26 21:52         ` Stefan Monnier
  2021-09-02 15:25           ` Daniel Brooks
  0 siblings, 1 reply; 525+ messages in thread
From: Stefan Monnier @ 2021-08-26 21:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, Clément Pit-Claudel, emacs-devel

> Indeed.  But I expect that whatever we end up with, we (that is, the
> Emacs maintainers) won't have to click around, and won't have to
> actually merge anything directly.  That is, I expect to have a command
> in Emacs that says "get that pull request as a patch, apply it, and
> don't commit it".  So that we can fix stuff up before committing -- as
> before.

Personally I tend to just use `git am` which *does* commit, and then
I use `--amend` or `rebase` to perform adjustments.  Git supports that
particularly well.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-26 21:41             ` [External] : " Drew Adams
@ 2021-08-26 21:52               ` Arthur Miller
  2021-08-30 16:30                 ` João Távora
  2021-08-27  6:21               ` tomas
  2021-08-27  6:29               ` [External] : Re: Gitlab Migration Eli Zaretskii
  2 siblings, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-26 21:52 UTC (permalink / raw)
  To: Drew Adams
  Cc: philipk, danflscr, emacs-devel, Dmitry Gutov, larsi, Eli Zaretskii

Drew Adams <drew.adams@oracle.com> writes:

>> Maybe Emacs project should be better at informing users 
>> about Emacs bug tracker: ... and this one: ... and
>> debbugs package for browsing bugs directly from Emacs?
>
> (Apologies for not really following this thread.)
>
> 1. It might not help with the general process of tracking
> or searching bugs, but we do have a `Help' menu item for
> submitting a bug report: `Send Bug Report'.  That should
> be an easy entry, in principle.
It is an easy entry, but it is not so much about reporting bugs, but
contributing to emacs. Some people think it is easier to search through web
bases "issues" interface to discover if their issue is already reported, covered
etc.

> Of course that just invokes `report-emacs-bug'.  Maybe
> the `report-emacs-bug' interaction scares some users and
> could be made less scary (dunno).
>
> 3. Something else that might help a bit is to include,
> in each mail sent to a bug thread, a debbugs.gnu.org 
> link to that post.

That sounds like a good idea in my eyes.

> 4. And yes, a web interface (at debbugs.gnu.org or not)
> that lets you not only view, but also reply to, posts
> would be good.
>
> 5. And debbugs.gnu.org search sucks.  Or at least I suck
> at trying to find anything using it.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:37       ` Dmitry Gutov
  2021-08-26 19:44         ` Eli Zaretskii
@ 2021-08-26 21:55         ` Stefan Monnier
  2021-08-27  6:00         ` tomas
  2 siblings, 0 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-26 21:55 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Eli Zaretskii, Clément Pit-Claudel, emacs-devel

>> If you have an email message that belongs to a bug, reply to it;
>> otherwise simply write to the bug address.
> ...and cut off all prior participants from the discussions. Except those who
> are subscribed to the mailing list, of course.

Indeed, this a major downside of debbugs.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 21:13             ` Dmitry Gutov
@ 2021-08-26 22:05               ` Arthur Miller
  0 siblings, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-26 22:05 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, Eli Zaretskii, danflscr, larsi, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 23:51, Arthur Miller wrote:
>
>>> The point is, someone who has never contributed before can more easily see all
>>> bugs/PRs/discussions from the outside, and when they file a PR, see the checks
>>> succeed or fail (with specific complaints and recommendations) without having to
>>> involve a live person.
>> Hmm, some projects have thousands of issues, some remove solved issues. I am not
>> sure it is so easily discoverable. Also I see a lot of comments on gh advising
>> users to first search for the issue before posting, which makes me thing that
>> people are not so good to "look first" if issue is already solved.
>
> I didn't mean to say it's perfect, just more manageable.
>
> And, like you say, a lot of users are already "trained" to look for prior
> discussions, prior issues, etc.

I ment they are not :-). Seems like many people are "asking first" instead of
"searching first". That is how I intepret tips on some github projects, to
search first before they report an issue.

If I find something problematic i usually do a web search, and than if SX,
Reddit and Google return nothing useful, than I consider sending a mail to the
list. That is why there are very few bugs I have reported :).

>
> We see people on Emacs Help asking similar questions over and over.
>
>>> The ability to avoid bothering anyone directly (and risk a negative reception)
>>> can help avoid some of the worries.
>> Maybe Emacs project should be better at informing users about Emacs bug
>> tracker:
>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>> and this one:
>> https://debbugs.gnu.org/
>> and debbugs package for browsing bugs directly from Emacs?
>
> They should be informed, yes, but our antiquated bug tracker is the main
> technical weak point of the project. Some of the previous messages which
> referred to difficulties in email-based workflow were actually about
> "email-based Debbugs workflow".

I understand. Now I don't want to be a devil's advocate here, but for me
M-x debbugs-gnu is a bit slow to load into Emacs, but once loaded I think it is
not much worse Githubs "issues" list on any project. I think it is preferable
since I can see all bugs back to version 23, instead of having to click through
pages on github. Maybe there is some better interface to github web service, I
haven't tried their cli tool, maybe I should, but I don't know.

When I open a bug repport in debbugs-gnu I see entire mailing list tree and I
also can click on any of messages and S-W to send a reply, regardless of how old
it is.

But yes, the difference is that on the web, any random user who is interested
about a project, can go to project page, and look through the list of
"issues". It is not so straightforward with Emacs indeed. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
                     ` (3 preceding siblings ...)
  2021-08-26 18:36   ` Clément Pit-Claudel
@ 2021-08-26 23:52   ` Tim Cross
  2021-08-28  2:59     ` Richard Stallman
  2021-08-27  7:00   ` Daniel Fleischer
                     ` (2 subsequent siblings)
  7 siblings, 1 reply; 525+ messages in thread
From: Tim Cross @ 2021-08-26 23:52 UTC (permalink / raw)
  To: emacs-devel


Philip Kaludercic <philipk@posteo.net> writes:

> Hi,
>
> Daniel Fleischer <danflscr@gmail.com> writes:
>
>> One issue which I think is important is the move to a new VC system,
>> e.g. Gitlab. I started reading the relevant threads and I'm not sure
>> where the issue stands today. Let me recap the benefits:
>>
>> 1 The need for new people to join the community and help. Newer
>>  (younger) people will be more familiar with the newer VC platforms
>>  (github/lab and similar). These are not only developers but regular
>>  users who want to report an issue (bug) or suggest a feature.
>
> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.
>

I certainly agree email is easy. However, I'm old. When I talk to young
people i.e. in their 20s, they simply don't use email. Yes, they have an
email address, but that is only because of places that insist on one.
They communicate/share information via slack, discord, reddit, instagram
etc. Email is what they use when forced to interact with 'old'
institutions (Government, Uni, Grandparents etc).

>>  Lowering the bar for participation is the key to growing Emacs and
>>  the community.
>
> I think that showing people that they biases against mailing list
> development might be illegitimate would be a viable alternative.
>

I'm not sure how we achieve that. For many, email just isn't a comms
channel they are interested in. Your unlikely to convince anyone of the
benefits when your referring to a technology which simply doens't factor
into their world.

The answer is more likely a solution which allows multiple workflow
styles with no loss of functionality.

>> 2 Having the code + issues + discussions in the same place as opposed
>>  to now, where the code and discussions (lists) are in 3 different
>>  places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
>>  modern VC system, one can jump easily between issues, discussions,
>>  code commits back and forth easily as opposed to now, where if it's a
>>  bug you can use its number to search lists and commits messages but
>>  if it's a discussion, it's not "connected" to anything.
>
> Correct me if I am wrong, but all the discussions are at least mirrored
> on the mailing lists. Savannah is just for project management and the
> GNU bug tracker uses the mailing list too. It is more uniform too, as
> everything is just a mail-message, not part of a forcefully linearized
> thread. Commenting on a issue, "pull request" or a patch is always just
> responding to a message.
>
> That being said, I wouldn't mind prettier web interface for the mailing
> list (I think that the Guix project is doing well on that front).
>

I suspect one of the things which made github so popular was that there
is little where you are forced to use only the web interface.
Admittedly, there are some things which take a little more effort or
setup to enable non-web UI access, but it is doable. From memory, Gitlab
was similar, but not quite and there are some functions which are either
restricted to web UI or need to be initiated via the web UI.

The solution is likely something which allows equal access via web UI,
email and command line. For example, an email gateway which creates
'pseudo' PRs, a 'shell' which allows full CLI interaction etc. 

>> Possible issue:
>>
>> 1 Being able to use Emacs for all these needs. One way is being able to
>>  interact with the VC system using emails, i.e. issues, features,
>>  discussions should have a nice and efficient email interface in
>>  addition to using a website. Another approach is using the wonderful
>>  Magit and Forge packages. Forge currently is lacking the discussions
>>  feature but has a very good git + pull-requests + org-mode
>>  integration abilities.
>
> I remember Sourceforge being suggested as an alternative to Gitlab, but
> the software is currently still in a beta stage (AFAIR).
>

There was also another repository which had a libre/free focus at all
levels/interfaces, but it too was more 'alpha' than 'beta' wrt
development status. 




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
                   ` (3 preceding siblings ...)
  2021-08-26 18:51 ` Stefan Monnier
@ 2021-08-27  0:37 ` Po Lu
  2021-08-27 13:35 ` Daniel Martín
  2021-08-28  2:59 ` Gitlab Migration Richard Stallman
  6 siblings, 0 replies; 525+ messages in thread
From: Po Lu @ 2021-08-27  0:37 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel

Daniel Fleischer <danflscr@gmail.com> writes:

> 1 The need for new people to join the community and help. Newer
>  (younger) people will be more familiar with the newer VC platforms
>  (github/lab and similar). These are not only developers but regular
>  users who want to report an issue (bug) or suggest a feature.
>  Lowering the bar for participation is the key to growing Emacs and
>  the community.

People mention youth.  I think recently there was an excellent article
written by someone who would definitely qualify as "youth", and posted
to one of the social media platforms frequented by youth, which
basically summed up the process as "initially intimidating, but actually
easy".

> 2 Having the code + issues + discussions in the same place as opposed
>  to now, where the code and discussions (lists) are in 3 different
>  places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
>  modern VC system, one can jump easily between issues, discussions,
>  code commits back and forth easily as opposed to now, where if it's a
>  bug you can use its number to search lists and commits messages but
>  if it's a discussion, it's not "connected" to anything.

And in GitLab, the code, issues and discussions are also in 3 separate
places: The repository, the issue tracker, and I'm not even sure what
the place for discussions is on these platforms.  Twitter perhaps?

> Possible issue:
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website. Another approach is using the wonderful
>  Magit and Forge packages. Forge currently is lacking the discussions
>  feature but has a very good git + pull-requests + org-mode
>  integration abilities.

Magit as a whole is nice, but Magit is not part of Emacs.  Forge may be
nice and all that, but has anyone found a way to use Gnus for
pull-requests?

Anyhow, I don't think any of these clients will solve the real problems
with these platforms.  Case in point: some time ago, I tried reporting
an issue on the Freedesktop.org GitLab instance, and tried to register
an account.  At first my browser froze and would not open the
registration form! After it did load, I had to resign myself to running
Google's reCaptcha, and even after that, the confirmation e-mail never
arrived and I gave up.  That seems to be a very high entry barrier for
new contributions.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:04     ` Eli Zaretskii
                         ` (2 preceding siblings ...)
  2021-08-26 20:09       ` Clément Pit-Claudel
@ 2021-08-27  0:38       ` Tim Cross
  2021-08-27  1:00         ` Jean-Christophe Helary
  3 siblings, 1 reply; 525+ messages in thread
From: Tim Cross @ 2021-08-27  0:38 UTC (permalink / raw)
  To: emacs-devel


Eli Zaretskii <eliz@gnu.org> writes:

>
> IOW, the most important reason for this move is to be more welcoming
> to casual contributors, not to make the job much easier for the
> maintainers.

I agree. Also worth noting that making it too easy to contribute is not
necessarily a positive. I have worked on and helped maintain projects
where the bar for contributing was too low and you ended up with far too
many low quality or completely misguided patches and contributions.

As an example, a recent new release in one project has resulted in a
number of patches that are completely unnecessary because the
functionality they fix/add was either already available or due to local
configuration problems. While this likely indicates a need for better
documentation, part of the issue is due to it being just too easy to
generate a PR, which is often fired off and then forgotten by the OP - a
sort of 'log and flog' mentality that results in lots more
contributions, but a much higher noise ratio which consumes valuable
maintainer time sorting and analysing.

The right level of resistance to contributing can be a positive provided
that level is set appropriately. Many of the discussions I've read about
barriers to contributing to Emacs seem to be centred around
discoverability rather than honours process. Perhaps addressing that
aspect would be worthwhile rather than trying to re-engineer a whole new
framework?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:31     ` Dmitry Gutov
  2021-08-26 19:41       ` Eli Zaretskii
@ 2021-08-27  0:40       ` Po Lu
  2021-08-27  1:31         ` Arthur Miller
  2021-08-27  1:01       ` Tim Cross
  2 siblings, 1 reply; 525+ messages in thread
From: Po Lu @ 2021-08-27  0:40 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Lars Ingebrigtsen, Philip Kaludercic, Daniel Fleischer, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> We also have a bunch of formal rules for submissions which tend to
> seem intimidating. A CI with an automated checker running against all
> PRs can alleviate that problem.

I don't know enough git to tell you exactly what it is, but perhaps
whatever runs each time I check-in something to my local copy of the
repository that checks for indentation and extraneous whitespace could
also work for this?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  0:38       ` Tim Cross
@ 2021-08-27  1:00         ` Jean-Christophe Helary
  0 siblings, 0 replies; 525+ messages in thread
From: Jean-Christophe Helary @ 2021-08-27  1:00 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

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



> On Aug 27, 2021, at 9:38, Tim Cross <theophilusx@gmail.com> wrote:
> 
> The right level of resistance to contributing can be a positive provided
> that level is set appropriately. Many of the discussions I've read about
> barriers to contributing to Emacs seem to be centred around
> discoverability rather than honours process. Perhaps addressing that
> aspect would be worthwhile rather than trying to re-engineer a whole new
> framework?


I found this blog article very valuable (even though I find the conclusion mistaken)
https://www.fosskers.ca/en/blog/contributing-to-emacs

There is nothing intrinsically difficult in using email for this process, and if email is defined as the "channel" through which contributions to emacs are made, I am sure young people will catch up very quickly.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/


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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:31     ` Dmitry Gutov
  2021-08-26 19:41       ` Eli Zaretskii
  2021-08-27  0:40       ` Po Lu
@ 2021-08-27  1:01       ` Tim Cross
  2021-08-27  7:07         ` Daniel Fleischer
  2021-09-01 17:15         ` Maxim Nikulin
  2 siblings, 2 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-27  1:01 UTC (permalink / raw)
  To: emacs-devel


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>> Many
>> don't use mail at all for development, and all they're used to is the
>> GitLab/Hub way of doing it.
>
> Email is used by virtually everyone (for example, to receive notifications about
> others' actions or messages), what's "unusual" for many is sending patches over
> email. Or inlining them in comments/messages.
>

I'm not sure this is true. I think virtually all developers are forced
to suffer email, but a gorwing number don't use it. Often, all the
discussions, notifications, comments etc are actually consumed via a
mobile 'app'. For these users, logging into their inbox is frustrating
and inconvenient because their inbox is full of pointless and old
messages/notifications/alerts they have already seen/received via other
channels. For these users, the primary reason they have an email address
is to have something to put into the 'login' box for web services they
use. Telling these users to use email to submit a patch is very similar
to me being told when I started using email that I had to send in a hard
copy via snail mail.

I love an email interface. Then again, I still miss newsgroups. I hate
web based 'groups' and avoid slack/discord whenever possible. However,
I'm an old white guy in his 60s and not representative of Emacs' future
even though I hope I still have some positive contributions to make.

We do need to look at how to support more modern/current engagement
models, but perhaps not at the expense of old proven ones. We need a
more flexible engagement model rather than replacement of the existing
one. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  0:40       ` Po Lu
@ 2021-08-27  1:31         ` Arthur Miller
  2021-08-27 11:33           ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-27  1:31 UTC (permalink / raw)
  To: Po Lu
  Cc: Lars Ingebrigtsen, emacs-devel, Daniel Fleischer,
	Philip Kaludercic, Dmitry Gutov

Po Lu <luangruo@yahoo.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> We also have a bunch of formal rules for submissions which tend to
>> seem intimidating. A CI with an automated checker running against all
>> PRs can alleviate that problem.
>
> I don't know enough git to tell you exactly what it is, but perhaps
> whatever runs each time I check-in something to my local copy of the
> repository that checks for indentation and extraneous whitespace could
> also work for this?

Couldn't identation and extraneous space be solved by either running after save
hook in Emacs, or by running emacs in batch mode as a git hook?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 20:09       ` Clément Pit-Claudel
@ 2021-08-27  5:51         ` Eli Zaretskii
  2021-08-27  6:04           ` Clément Pit-Claudel
  2021-08-27  6:10           ` Tim Cross
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27  5:51 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 26 Aug 2021 16:09:32 -0400
> 
> On 8/26/21 3:04 PM, Eli Zaretskii wrote:
> > It's actually the other way around, at least in some cases.  With
> > patches that are emailed to me, I can fix some simple issues, such as
> > commit log messages or simple typos, myself, before applying.  With
> > merging via Web UI, I need to push another commit, which is a waste,
> > and also breaks what should have been a single commit into several
> > ones.  So with Web UI, I expect _more_ requests to contributors to get
> > their act together, where automated fixups are impossible, because
> > there's little I can do myself.
> 
> Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?

AFAIK, merging a PM is usually a UI action.  But if it is done
manually like you describe, then there's no difference, and no
advantage to either method.

> >> - Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?
> > 
> > I think you see problems where there are none.  If you have an email
> > message that belongs to a bug, reply to it; otherwise simply write to
> > the bug address.  admin/notes/bugtracker explains this within its
> > first dozen of lines.
> 
> This is in line with what I wrote above: there is a process that is specific to Emacs, and it requires reading a document that is specific to Emacs to get it right (and you have to find that document).

I've yet to see a serious project of reasonably large size and age
that didn't have such a document.  Coding conventions and patch
submission conventions vary among projects and change with time, and
keeping them unwritten is not a good idea.

> >> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.
> > 
> > I realize that some people who want to contribute don't like emacs or
> > are intimidated by it. 
> 
> I would be surprised if anyone who wants to contribute patches to Emacs doesn't like Emacs.  Maybe I'm misunderstanding what you're saying.

I meant email.  Sometimes my fingers think they know better what I
mean.

> > That's an important reason to provide the UI
> > to which they are more accustomed.  But let's not exaggerate the
> > advantages of these platforms for the Emacs developers: though some
> > advantages exist, they are not that significant, at least IMO, and
> > there are disadvantages (described in the GitLab issue).
> 
> And yet few of the packages hosted on MELPA — even those that don't get many external contributions — are developed using mailing lists (not sure about GNU ELPA).  That might suggest that even Emacs veterans see value in these online systems (?)

I didn't say there was no value, I said let's not exaggerate the
advantages.

And there's a difference between maintaining a project with perhaps
several Ks or several dozen Ks of lines, and maintaining Emacs.  With
Emacs we need all the power of the development environment
conveniently integrated in the same place; we need Emacs itself.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:37       ` Dmitry Gutov
  2021-08-26 19:44         ` Eli Zaretskii
  2021-08-26 21:55         ` Stefan Monnier
@ 2021-08-27  6:00         ` tomas
  2021-08-27  7:36           ` Structured debbugs list per project (was: Gitlab Migration) Michael Albinus
  2021-08-27 11:25           ` Gitlab Migration Dmitry Gutov
  2 siblings, 2 replies; 525+ messages in thread
From: tomas @ 2021-08-27  6:00 UTC (permalink / raw)
  To: emacs-devel

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

On Thu, Aug 26, 2021 at 10:37:32PM +0300, Dmitry Gutov wrote:
> On 26.08.2021 22:04, Eli Zaretskii wrote:
> >If you have an email
> >message that belongs to a bug, reply to it; otherwise simply write to
> >the bug address.
> 
> ...and cut off all prior participants from the discussions. Except
> those who are subscribed to the mailing list, of course.

There's no reason to not have a web accessible bug mail archive
indexed by bug number, for the webby folks our there. Perhaps
debbugs could implement that... oh wait [1]!

SCNR

[1] https://debbugs.gnu.org/db/pa/lemacs.html

 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  5:51         ` Eli Zaretskii
@ 2021-08-27  6:04           ` Clément Pit-Claudel
  2021-08-27  6:10           ` Tim Cross
  1 sibling, 0 replies; 525+ messages in thread
From: Clément Pit-Claudel @ 2021-08-27  6:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On 8/27/21 1:51 AM, Eli Zaretskii wrote:
>> Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?
> 
> AFAIK, merging a PM is usually a UI action.  But if it is done
> manually like you describe, then there's no difference, and no
> advantage to either method.

The UI action is available, but merging the branch in the git repository is enough.  The difference is (through forks) that every patch has its own branch.

> I've yet to see a serious project of reasonably large size and age
> that didn't have such a document.  Coding conventions and patch
> submission conventions vary among projects and change with time, and
> keeping them unwritten is not a good idea.

Of course.  The nice part about the web UIs is that bug-reporting instructions pop up automatically when you press the "report bug" button.

> And there's a difference between maintaining a project with perhaps
> several Ks or several dozen Ks of lines, and maintaining Emacs.  With
> Emacs we need all the power of the development environment
> conveniently integrated in the same place; we need Emacs itself.

Of course.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 20:51           ` Arthur Miller
  2021-08-26 21:13             ` Dmitry Gutov
  2021-08-26 21:41             ` [External] : " Drew Adams
@ 2021-08-27  6:09             ` Eli Zaretskii
  2021-08-28  1:51               ` Arthur Miller
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27  6:09 UTC (permalink / raw)
  To: Arthur Miller; +Cc: philipk, emacs-devel, danflscr, larsi, dgutov

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 26 Aug 2021 22:51:41 +0200
> Cc: philipk@posteo.net, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com,
>  larsi@gnus.org, emacs-devel@gnu.org
> 
> Maybe Emacs project should be better at informing users about Emacs bug tracker:
> 
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
> 
> and this one:
> 
> https://debbugs.gnu.org/

It's mentioned on line 45 of CONTRIBUTE, near the beginning of the
"Getting involved with development" section.

> and debbugs package for browsing bugs directly from Emacs?

The debbugs package has several non-trivial dependencies, like email,
and is probably not the first or the second thing newcomers should be
messing with.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  5:51         ` Eli Zaretskii
  2021-08-27  6:04           ` Clément Pit-Claudel
@ 2021-08-27  6:10           ` Tim Cross
  2021-08-27  8:26             ` Andreas Schwab
  2021-08-27 11:28             ` Eli Zaretskii
  1 sibling, 2 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-27  6:10 UTC (permalink / raw)
  To: emacs-devel


Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 26 Aug 2021 16:09:32 -0400
>> 
>> On 8/26/21 3:04 PM, Eli Zaretskii wrote:
>> > It's actually the other way around, at least in some cases.  With
>> > patches that are emailed to me, I can fix some simple issues, such as
>> > commit log messages or simple typos, myself, before applying.  With
>> > merging via Web UI, I need to push another commit, which is a waste,
>> > and also breaks what should have been a single commit into several
>> > ones.  So with Web UI, I expect _more_ requests to contributors to get
>> > their act together, where automated fixups are impossible, because
>> > there's little I can do myself.
>> 
>> Oh, that's not how it typically works in the project that I contribute to (and
>> that I maintain): the maintainer often makes small fixes before merging,
>> amends the relevant commits with those changes, and then merge using "git
>> merge". Did I misunderstand?
>
> AFAIK, merging a PM is usually a UI action.  But if it is done
> manually like you describe, then there's no difference, and no
> advantage to either method.
>
It is really up to the individual. Github for exmaple, provides
instructions for merging PRs using either the web UI or the command
line. For the CLI, you are adding the remote PR as a 'remote' to your
local git repository. You can then check it out as a branch, review,
modify and test. If satisfied, you then just merge into your main branch
(or whatever branch is appropriate), push it up and close the PR.

Many people will just use the web UI. Personally, I prefer the CLI
approach as I like the additional control. At this level, it isn't
much different to how I imagine Emacs maintainers currently deal with
email patches i.e. checkout a fresh branch, apply the patch to that
branch, evaluate and if appropriate, merge into main branch.

The PR approach does have advantages, especially for those submitting
the PR. It can provide some useful immediate feedback (especially if
some of the advanced actions are used to perform common checks or policy
validation), provides a single definitive place, potentially including
review/comment history and changes and could be setup to help reduce
demands on core maintainers (for example, might require review by one or
more reviewers, who could be trusted volunteers who are comfortable to
assist with reviewing, but perhaps not with the responsibility of
merging). Core maintainers can then focus on just those PRs which have
been reviewed and avoiding wasting their limited time on things others
can deal with.

However, it seems the main issue isn't whether these so called 'modern'
workflows are a bad idea, but rather whether there is software which
implements these workflows which is FSF compliant. The best course of
action might be for those who would like to see adoption of these
workflows contribute to projects which are FSF compliant - perhaps
projects like sourceHut and help get a solution to a satisfactory
standard that it could be used by Emacs (and other GNU projects). Until
software is identified which meet FSF requirements, little can change
and debating the merits is largely pointless. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-26 21:41             ` [External] : " Drew Adams
  2021-08-26 21:52               ` Arthur Miller
@ 2021-08-27  6:21               ` tomas
  2021-08-27  7:23                 ` Debbugs state (was: [External] : Re: Gitlab Migration) Michael Albinus
  2021-08-30 11:42                 ` gebbugs.gnu.org search (was Re: Gitlab Migration) Maxim Nikulin
  2021-08-27  6:29               ` [External] : Re: Gitlab Migration Eli Zaretskii
  2 siblings, 2 replies; 525+ messages in thread
From: tomas @ 2021-08-27  6:21 UTC (permalink / raw)
  To: emacs-devel

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

On Thu, Aug 26, 2021 at 09:41:06PM +0000, Drew Adams wrote:
> > Maybe Emacs project should be better at informing users 
> > about Emacs bug tracker: ... and this one: ... and
> > debbugs package for browsing bugs directly from Emacs?
> 
> (Apologies for not really following this thread.)

[...]

> 5. And debbugs.gnu.org search sucks.  Or at least I suck
> at trying to find anything using it.

My starting point would be something like [1].

(And yes, I think we old jeezers have the responsibility to show
folks ways to use the Internet instead of being used by it ;-)

There is some obvious low hanging fruit there, the first which comes
to mind would be to add a subdomain for each package: this would
leverage the search engine's `site' filter.

Of course there's that higher hanging fruit: add a useful search
facility to debbugs. I hear that there are project funding resources
with Debian in search of a project [2]. Perhaps Gnu and Debian could
band together for that? Some GSOC?

Cheers

[1] https://html.duckduckgo.com/html?q=redisplay+idle+site:debbugs.gnu.org
[2] https://salsa.debian.org/freexian-team/project-funding

 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:38       ` dick
  2021-08-26 19:51         ` Eli Zaretskii
@ 2021-08-27  6:26         ` tomas
  2021-08-27 12:11           ` dick
  2021-09-02 11:06         ` Alexander Adolf
  2 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-27  6:26 UTC (permalink / raw)
  To: dick; +Cc: danflscr, emacs-devel

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

On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
> * Newcomer suggests PR-based workflow citing youth.  Check.

[rest deleted]

And this was useful why exactly?

Look. If you have something constructive to contribute, go ahead.

somewhat disgusted
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-26 21:41             ` [External] : " Drew Adams
  2021-08-26 21:52               ` Arthur Miller
  2021-08-27  6:21               ` tomas
@ 2021-08-27  6:29               ` Eli Zaretskii
  2021-08-27  7:25                 ` Drew Adams
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27  6:29 UTC (permalink / raw)
  To: Drew Adams; +Cc: philipk, danflscr, emacs-devel, arthur.miller, dgutov, larsi

> From: Drew Adams <drew.adams@oracle.com>
> Date: Thu, 26 Aug 2021 21:41:06 +0000
> Cc: "larsi@gnus.org" <larsi@gnus.org>,
>  "philipk@posteo.net" <philipk@posteo.net>,
>  "danflscr@gmail.com" <danflscr@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> 5. And debbugs.gnu.org search sucks.  Or at least I suck
> at trying to find anything using it.

I actually find the debbugs search engine superior to at least what we
have on the mailing lists.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:13   ` john muhl
@ 2021-08-27  6:50     ` Daniel Fleischer
  2021-08-27 11:20       ` Eli Zaretskii
  2021-08-27 23:13       ` Yuchen Pei
  0 siblings, 2 replies; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-27  6:50 UTC (permalink / raw)
  To: john muhl; +Cc: emacs-devel

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

john muhl [2021-08-26 Thu 14:13]  *wrote*:

> On Thu, 2021-08-26 at 14:51 -0400, Stefan Monnier wrote:
>> 
>> The last I heard from this is that some software was considered and
>> there was a web page summarizing the status, but that was maybe 2
>> years ago and I can't find that page any more
>
> maybe one on these:
> <https://libreplanet.org/wiki/FSF_2020_forge_evaluation>
> <https://www.gnu.org/software/repo-criteria-evaluation.html>

According to the forge evaluation link it seems Gitlab is not really an
option and the front runner is Fedora's Pagure. Are the people that did
the evaluation participate in this list? Where do things stand with
Pagure?

*Daniel Fleischer*

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
                     ` (4 preceding siblings ...)
  2021-08-26 23:52   ` Tim Cross
@ 2021-08-27  7:00   ` Daniel Fleischer
  2021-08-27  7:16     ` Tim Cross
  2021-08-27 11:30     ` Eli Zaretskii
  2021-08-27 18:02   ` Augusto Stoffel
  2021-08-28  2:59   ` Richard Stallman
  7 siblings, 2 replies; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-27  7:00 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

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

Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:

> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.

I explicitly don't want to get into questions of what is easier because
we can't answer these objectively. Each person is used to something else
which they consider easier, where the getting used to is a long
mental process depending on personal preference and outside influence.

I can say objectively that one form of workflow is more popular than
another so people would be more familiar with it.

*Daniel Fleischer*

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  1:01       ` Tim Cross
@ 2021-08-27  7:07         ` Daniel Fleischer
  2021-08-27  7:34           ` Tim Cross
  2021-09-01 17:15         ` Maxim Nikulin
  1 sibling, 1 reply; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-27  7:07 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

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

Tim Cross [2021-08-27 Fri 11:01]  *wrote*:

> I'm not sure this is true. I think virtually all developers are forced
> to suffer email, but a gorwing number don't use it. Often, all the
> discussions, notifications, comments etc are actually consumed via a
> mobile 'app'. For these users, logging into their inbox is frustrating
> and inconvenient because their inbox is full of pointless and old
> messages/notifications/alerts they have already seen/received via other
> channels. For these users, the primary reason they have an email address
> is to have something to put into the 'login' box for web services they
> use. Telling these users to use email to submit a patch is very similar
> to me being told when I started using email that I had to send in a hard
> copy via snail mail.

It's a very intersting point about what email represent to different
people that arising from this discussion. I'm half your age and use
email for 2 reasons:

1. It's an identify for today's web. As such, it's becoming the main
   tool for tracking (especially as cookies phase out), so I use
   multiple boxes and regard them is disposable and spam-infected.

2. Receiving official documents from institutions.

I don't talk to family, friends or coworkers via mail. Personally, I
think it's old, not secure or private by default, very inconsistent
(HTML rendering is arbitrary vs. text, multiple MUA) and just can't
imagine using it as a software engineering tool.

*Daniel Fleischer*

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  7:00   ` Daniel Fleischer
@ 2021-08-27  7:16     ` Tim Cross
  2021-08-27 11:30     ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-27  7:16 UTC (permalink / raw)
  To: emacs-devel


Daniel Fleischer <danflscr@gmail.com> writes:

> Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:
>
>> Shouldn't it be easier to send an email than create an account, navigate
>> some web UI and fill in some form? The same goes for
>> patches. Git{Lab,Hub} usually requires leaving the development context,
>> to prepare a patch online, that requires "forking", more navigation and
>> more fora. Just today I tried preparing a "pull request" on GitLab and
>> didn't manage to do so, because it insisted on merging the commit into
>> my own repository, no matter what I did. Just attaching a git patch
>> seems much easier.
>
> I explicitly don't want to get into questions of what is easier because
> we can't answer these objectively. Each person is used to something else
> which they consider easier, where the getting used to is a long
> mental process depending on personal preference and outside influence.
>
> I can say objectively that one form of workflow is more popular than
> another so people would be more familiar with it.
>

I also don't think it is an either/or choice. It should be possible to
support both email based workflows as well as web UI based ones. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Debbugs state (was: [External] : Re: Gitlab Migration)
  2021-08-27  6:21               ` tomas
@ 2021-08-27  7:23                 ` Michael Albinus
  2021-08-27  7:40                   ` tomas
  2021-08-30 11:42                 ` gebbugs.gnu.org search (was Re: Gitlab Migration) Maxim Nikulin
  1 sibling, 1 reply; 525+ messages in thread
From: Michael Albinus @ 2021-08-27  7:23 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

<tomas@tuxteam.de> writes:

> Of course there's that higher hanging fruit: add a useful search
> facility to debbugs. I hear that there are project funding resources
> with Debian in search of a project [2]. Perhaps Gnu and Debian could
> band together for that? Some GSOC?

The debbugs project in Debian has moved forward a lot since we have
forked back in 2008 (?). We shall merge.

This was planned already a while ago, but it has stalled
since. Volunteers welcome!

> Cheers

Best regards, Michael.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-27  6:29               ` [External] : Re: Gitlab Migration Eli Zaretskii
@ 2021-08-27  7:25                 ` Drew Adams
  0 siblings, 0 replies; 525+ messages in thread
From: Drew Adams @ 2021-08-27  7:25 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, emacs-devel, arthur.miller, dgutov, larsi

> > 5. And debbugs.gnu.org search sucks.  Or at least I suck
> > at trying to find anything using it.
> 
> I actually find the debbugs search engine superior to at least what we
> have on the mailing lists.

It may be superior; I have no idea, as I'm inferior to it.

I can easily search the emails I hold onto.  Easily and
flexibly.  Not that searching emails with an email client
is ideal, but at least a mortal can find things that way.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  7:07         ` Daniel Fleischer
@ 2021-08-27  7:34           ` Tim Cross
  2021-08-27  8:25             ` tomas
  2021-08-28  1:39             ` Arthur Miller
  0 siblings, 2 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-27  7:34 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel


Daniel Fleischer <danflscr@gmail.com> writes:

> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>
>> I'm not sure this is true. I think virtually all developers are forced
>> to suffer email, but a gorwing number don't use it. Often, all the
>> discussions, notifications, comments etc are actually consumed via a
>> mobile 'app'. For these users, logging into their inbox is frustrating
>> and inconvenient because their inbox is full of pointless and old
>> messages/notifications/alerts they have already seen/received via other
>> channels. For these users, the primary reason they have an email address
>> is to have something to put into the 'login' box for web services they
>> use. Telling these users to use email to submit a patch is very similar
>> to me being told when I started using email that I had to send in a hard
>> copy via snail mail.
>
> It's a very intersting point about what email represent to different
> people that arising from this discussion. I'm half your age and use
> email for 2 reasons:
>
> 1. It's an identify for today's web. As such, it's becoming the main
>    tool for tracking (especially as cookies phase out), so I use
>    multiple boxes and regard them is disposable and spam-infected.
>
> 2. Receiving official documents from institutions.
>
> I don't talk to family, friends or coworkers via mail. Personally, I
> think it's old, not secure or private by default, very inconsistent
> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
> imagine using it as a software engineering tool.
>

Yep, that mirrors what I'm seeing as well. Many younger users really use
it primarily to provide a unique identifier (login) and for when they
have to deal with institutions that don't provide other alternatives.

The other interesting trend I'm seeing is with many companies now
working to minimise email as part of their internal/external workflows.
Many companies are finding it a huge resource sink, cause of unnecessary
stress/pressure on staff, source of significant security concerns and a
real problem for records management.

From the Emacs project perspective, providing alternative web based
workflows similar to what github/gitlab/sourceHut provide would be
beneficial. The challenge seems to be in finding software which meets
FSF requirements. In particular, a solution which is mature enough and
is not based on non-free Javascript libraries. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Structured debbugs list per project (was: Gitlab Migration)
  2021-08-27  6:00         ` tomas
@ 2021-08-27  7:36           ` Michael Albinus
  2021-08-27  7:38             ` tomas
  2021-08-27 11:25           ` Gitlab Migration Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Michael Albinus @ 2021-08-27  7:36 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

<tomas@tuxteam.de> writes:

> There's no reason to not have a web accessible bug mail archive
> indexed by bug number, for the webby folks our there. Perhaps
> debbugs could implement that... oh wait [1]!
>
> SCNR
>
> [1] https://debbugs.gnu.org/db/pa/lemacs.html

Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
hard.

>  - t

Best regards, Michael.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Structured debbugs list per project (was: Gitlab Migration)
  2021-08-27  7:36           ` Structured debbugs list per project (was: Gitlab Migration) Michael Albinus
@ 2021-08-27  7:38             ` tomas
  2021-08-28  1:52               ` Structured debbugs list per project Arthur Miller
  2021-08-28 15:43               ` Michael Albinus
  0 siblings, 2 replies; 525+ messages in thread
From: tomas @ 2021-08-27  7:38 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel

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

On Fri, Aug 27, 2021 at 09:36:52AM +0200, Michael Albinus wrote:
> <tomas@tuxteam.de> writes:
> 
> > There's no reason to not have a web accessible bug mail archive
> > indexed by bug number, for the webby folks our there. Perhaps
> > debbugs could implement that... oh wait [1]!
> >
> > SCNR
> >
> > [1] https://debbugs.gnu.org/db/pa/lemacs.html
> 
> Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
> hard.

Michael, you rock :)

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Debbugs state (was: [External] : Re: Gitlab Migration)
  2021-08-27  7:23                 ` Debbugs state (was: [External] : Re: Gitlab Migration) Michael Albinus
@ 2021-08-27  7:40                   ` tomas
  2021-08-27 10:24                     ` Debbugs state Michael Albinus
  0 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-27  7:40 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel

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

On Fri, Aug 27, 2021 at 09:23:56AM +0200, Michael Albinus wrote:
> <tomas@tuxteam.de> writes:
> 
> > Of course there's that higher hanging fruit: add a useful search
> > facility to debbugs. I hear that there are project funding resources
> > with Debian in search of a project [2]. Perhaps Gnu and Debian could
> > band together for that? Some GSOC?
> 
> The debbugs project in Debian has moved forward a lot since we have
> forked back in 2008 (?). We shall merge.
> 
> This was planned already a while ago, but it has stalled
> since. Volunteers welcome!

Is there an entry point?

Thanks& cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  7:34           ` Tim Cross
@ 2021-08-27  8:25             ` tomas
  2021-08-27  9:47               ` Tim Cross
                                 ` (3 more replies)
  2021-08-28  1:39             ` Arthur Miller
  1 sibling, 4 replies; 525+ messages in thread
From: tomas @ 2021-08-27  8:25 UTC (permalink / raw)
  To: emacs-devel

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

On Fri, Aug 27, 2021 at 05:34:26PM +1000, Tim Cross wrote:

[...]

> Yep, that mirrors what I'm seeing as well. Many younger users really use
> it primarily to provide a unique identifier (login) and for when they
> have to deal with institutions that don't provide other alternatives.

I think part of the rush is nudge pressure applied by the Big Ones.
It's not possible to monetise mail in the same way as it is possible
to do with whatsapp, tiktok, twitter and the uncountable more or less
"secure" messengers popping up here and there.

The nice thing about those communications platforms (nice from the
perspective of the venture capitalist) is that there's no separation
of platform and UI, so they get direct control of the user's perception.

I opt out of that. Count me in whenever there is a platform which
separates transport and clients the way mail does and has at least
some choice of client applications with a perspective of diversity.

> The other interesting trend I'm seeing is with many companies now
> working to minimise email as part of their internal/external workflows.
> Many companies are finding it a huge resource sink, cause of unnecessary
> stress/pressure on staff, source of significant security concerns and a
> real problem for records management.

I have watched this process around the 2010s in one company. The
decision was made at top level (they were convinced by some Microsoft 
salesperson [1] to switch to Office 365 instead of mail, because...
mail is old). Today, they still use mail, but have outsourced their
whole communications infrastructure to Microsoft, GDPR be dammed.

The resource sink, stress and pressure stemmed rather from that
change, for those who had to use that "new" platform (not to
talk about staff layoffs for the old sysadmins, but I disgress).

Those having taken the decisions didn't have to use O365, they
have secretaries. For them, it was success.

This may sound like an off-topic rant, but I'm serious. Not all
of this "mail is old" meme is for real. Some of it is propaganda
(I emphasise: /some/ of it). So we should take each critique
and address it one by one.

To put it in other words: I won't pay a wholesale-ish "mail is
old" argument. I want to have more solid stuff.

Cheers

[1] https://en.wikipedia.org/wiki/Gr%C3%ADma

 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:10           ` Tim Cross
@ 2021-08-27  8:26             ` Andreas Schwab
  2021-08-27 11:28             ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Andreas Schwab @ 2021-08-27  8:26 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

On Aug 27 2021, Tim Cross wrote:

> For the CLI, you are adding the remote PR as a 'remote' to your local
> git repository.

You don't even need to add a remote, the contents of the PR is available
as a ref in a non-default namespace.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  8:25             ` tomas
@ 2021-08-27  9:47               ` Tim Cross
  2021-08-27 10:44                 ` tomas
                                   ` (2 more replies)
  2021-08-27 11:49               ` Eli Zaretskii
                                 ` (2 subsequent siblings)
  3 siblings, 3 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-27  9:47 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel


<tomas@tuxteam.de> writes:

> [[PGP Signed Part:Undecided]]
> On Fri, Aug 27, 2021 at 05:34:26PM +1000, Tim Cross wrote:
>
> [...]
>
>> Yep, that mirrors what I'm seeing as well. Many younger users really use
>> it primarily to provide a unique identifier (login) and for when they
>> have to deal with institutions that don't provide other alternatives.
>
> I think part of the rush is nudge pressure applied by the Big Ones.
> It's not possible to monetise mail in the same way as it is possible
> to do with whatsapp, tiktok, twitter and the uncountable more or less
> "secure" messengers popping up here and there.
>
> The nice thing about those communications platforms (nice from the
> perspective of the venture capitalist) is that there's no separation
> of platform and UI, so they get direct control of the user's perception.
>
>

The problem with that argument is that it doesn't explain the behaviour
of young adults and teenagers. Nobody has 'nudged' them to move away
from email - they were never into it. It simply isn't a communication
medium they are interested in. For them, it is about IM, instagram,
tiktok etc. Some of it is because of marketing, a lot of it is because
of peer influences. Regardless, email is of no interest to them. 

>> The other interesting trend I'm seeing is with many companies now
>> working to minimise email as part of their internal/external workflows.
>> Many companies are finding it a huge resource sink, cause of unnecessary
>> stress/pressure on staff, source of significant security concerns and a
>> real problem for records management.
>
> I have watched this process around the 2010s in one company. The
> decision was made at top level (they were convinced by some Microsoft 
> salesperson [1] to switch to Office 365 instead of mail, because...
> mail is old). Today, they still use mail, but have outsourced their
> whole communications infrastructure to Microsoft, GDPR be dammed.
>
> The resource sink, stress and pressure stemmed rather from that
> change, for those who had to use that "new" platform (not to
> talk about staff layoffs for the old sysadmins, but I disgress).
>
> Those having taken the decisions didn't have to use O365, they
> have secretaries. For them, it was success.

The move to use o365 or google mail was about moving away from
maintenance of infrastructure in favour of using 'commodity' services.
It is about streamlining management, reducing dependency on in-house
technical skills and more predictable and easy to manage budgets. This
was particularly true for companies who already used exchange and were
paying dearly for the cost (both technical and hardware) to maintain
the platform. It was also about the dream of unified communications with
Calendaring, VoIP, Video Conferencing, etc. Few companies just ran a
simple Postfix or similar mail server - they had calendaring systems,
video conferencing/meeting systems, VoIP systems etc., all of which
could be replaced by services from MS or Google and they could get rid
of those expensive and difficult to recruit skilled technical staff who
kept it all running. It was about easier management and predictable
budgets (even when it was more expensive).

However, this largely pre-dates the drive to move away from email.
Email, regardless how it is provided, is a problem for companies. It is
a major source of security problem, it is a nightmare for records
management, policy and regulation compliance and a major impediment in
business workflow automation. While I doubt any company will stop using
email completely, they are definitely moving way from having it as a key
technology in their business processes. 

>
> This may sound like an off-topic rant, but I'm serious. Not all
> of this "mail is old" meme is for real. Some of it is propaganda
> (I emphasise: /some/ of it). So we should take each critique
> and address it one by one.
>
The problems with email for business are real. While lots of companies
are pushing their alternative solutions for various reasons, it doesn't
remove the reality that it fails for business on many levels.
Personally, it remains my preferred communication medium, except when I
need to communicate with my kids or any of their friends!  

> To put it in other words: I won't pay a wholesale-ish "mail is
> old" argument. I want to have more solid stuff.
>

Time will tell. I certainly wouldn't be investing in any company that
was only an email provider. However, we are getting off topic. I think
the key point to note is that I don't think anyone is saying we need to
get rid of the email based stuff we currently have - what people are
asking for is to have an alternative interface which is similar to what
is offered by Github/Gitlab/sourceHut in addition, not instead of.
Arguments about one being better than the other are pointless as we all
have our own preferences. What people are asking for is support for a
broader set of preferences. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Debbugs state
  2021-08-27  7:40                   ` tomas
@ 2021-08-27 10:24                     ` Michael Albinus
  2021-08-27 10:51                       ` tomas
  0 siblings, 1 reply; 525+ messages in thread
From: Michael Albinus @ 2021-08-27 10:24 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

tomas@tuxteam.de writes:

Hi Tomas,

>> The debbugs project in Debian has moved forward a lot since we have
>> forked back in 2008 (?). We shall merge.
>>
>> This was planned already a while ago, but it has stalled
>> since. Volunteers welcome!
>
> Is there an entry point?

bug#26380, bug#43073

> Thanks& cheers
>  - t

Best regards, Michael.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  9:47               ` Tim Cross
@ 2021-08-27 10:44                 ` tomas
  2021-08-27 11:54                 ` Eli Zaretskii
  2021-08-27 16:59                 ` [External] : " Drew Adams
  2 siblings, 0 replies; 525+ messages in thread
From: tomas @ 2021-08-27 10:44 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

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

On Fri, Aug 27, 2021 at 07:47:33PM +1000, Tim Cross wrote:

[...] However, we are getting off topic [...]

Agreed. Feel free to contact me off-list if you wish to
continue that discussion. I do have different views wrt
a couple of things in your thoughtful reply, but they
definitely don't belong here :-)

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Debbugs state
  2021-08-27 10:24                     ` Debbugs state Michael Albinus
@ 2021-08-27 10:51                       ` tomas
  0 siblings, 0 replies; 525+ messages in thread
From: tomas @ 2021-08-27 10:51 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel

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

On Fri, Aug 27, 2021 at 12:24:14PM +0200, Michael Albinus wrote:
> tomas@tuxteam.de writes:
> 
> Hi Tomas,
> 
> >> [...] Volunteers welcome!
> >
> > Is there an entry point?
> 
> bug#26380, bug#43073

Thanks :)

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:50     ` Daniel Fleischer
@ 2021-08-27 11:20       ` Eli Zaretskii
  2021-08-27 23:13       ` Yuchen Pei
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 11:20 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel, email

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Fri, 27 Aug 2021 09:50:31 +0300
> Cc: emacs-devel@gnu.org
> 
> According to the forge evaluation link it seems Gitlab is not really an
> option and the front runner is Fedora's Pagure. Are the people that did
> the evaluation participate in this list?

Not to the best of my knowledge.

> Where do things stand with Pagure?

I don't think we seriously evaluated it.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:00         ` tomas
  2021-08-27  7:36           ` Structured debbugs list per project (was: Gitlab Migration) Michael Albinus
@ 2021-08-27 11:25           ` Dmitry Gutov
  1 sibling, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-27 11:25 UTC (permalink / raw)
  To: tomas, emacs-devel

On 27.08.2021 09:00, tomas@tuxteam.de wrote:
> There's no reason to not have a web accessible bug mail archive
> indexed by bug number, for the webby folks our there. Perhaps
> debbugs could implement that... oh wait [1]!

How does it help not to cut off previous participants from the 
discussion when you write a new message?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:10           ` Tim Cross
  2021-08-27  8:26             ` Andreas Schwab
@ 2021-08-27 11:28             ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 11:28 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

> From: Tim Cross <theophilusx@gmail.com>
> Date: Fri, 27 Aug 2021 16:10:03 +1000
> 
> > AFAIK, merging a PM is usually a UI action.  But if it is done
> > manually like you describe, then there's no difference, and no
> > advantage to either method.
> >
> It is really up to the individual. Github for exmaple, provides
> instructions for merging PRs using either the web UI or the command
> line. For the CLI, you are adding the remote PR as a 'remote' to your
> local git repository. You can then check it out as a branch, review,
> modify and test. If satisfied, you then just merge into your main branch
> (or whatever branch is appropriate), push it up and close the PR.

I know that one can do all that in Git commands, but the issue at hand
was the claim that PR workflow has advantages for the person who
merges the PR.  As I say above, if one does that via plain Git
commands, I see no advantages.

> (for example, might require review by one or more reviewers, who
> could be trusted volunteers who are comfortable to assist with
> reviewing, but perhaps not with the responsibility of merging).

These all are moot points for Emacs, because the people and roles you
describe simply don't exist.

> However, it seems the main issue isn't whether these so called 'modern'
> workflows are a bad idea, but rather whether there is software which
> implements these workflows which is FSF compliant.

I don't agree that this is the main issue.  It is an important factor,
yes.  But until we find a platform that fits the needs, it is also a
moot point, IMO.

> Until software is identified which meet FSF requirements, little can
> change and debating the merits is largely pointless.

I think it's the other way around: we need first to identify the
platform that fits our basic needs or can be extended to do that;
until we do that, it's pointless to look at the political issues.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  7:00   ` Daniel Fleischer
  2021-08-27  7:16     ` Tim Cross
@ 2021-08-27 11:30     ` Eli Zaretskii
  2021-08-27 14:33       ` Stefan Monnier
  2021-08-27 18:19       ` João Távora
  1 sibling, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 11:30 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: philipk, emacs-devel

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Fri, 27 Aug 2021 10:00:10 +0300
> Cc: emacs-devel@gnu.org
> 
> Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:
> 
> > Shouldn't it be easier to send an email than create an account, navigate
> > some web UI and fill in some form? The same goes for
> > patches. Git{Lab,Hub} usually requires leaving the development context,
> > to prepare a patch online, that requires "forking", more navigation and
> > more fora. Just today I tried preparing a "pull request" on GitLab and
> > didn't manage to do so, because it insisted on merging the commit into
> > my own repository, no matter what I did. Just attaching a git patch
> > seems much easier.
> 
> I explicitly don't want to get into questions of what is easier because
> we can't answer these objectively. Each person is used to something else
> which they consider easier, where the getting used to is a long
> mental process depending on personal preference and outside influence.

Agreed.  We don't need to force everyone to use a single workflow.  We
should have a platform that supports reasonably well the different
popular workflows.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  1:31         ` Arthur Miller
@ 2021-08-27 11:33           ` Dmitry Gutov
  2021-08-28  5:05             ` Arthur Miller
  2021-08-29  1:27             ` Po Lu
  0 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-27 11:33 UTC (permalink / raw)
  To: Arthur Miller, Po Lu
  Cc: Lars Ingebrigtsen, Daniel Fleischer, Philip Kaludercic, emacs-devel

On 27.08.2021 04:31, Arthur Miller wrote:
>>> We also have a bunch of formal rules for submissions which tend to
>>> seem intimidating. A CI with an automated checker running against all
>>> PRs can alleviate that problem.
>> I don't know enough git to tell you exactly what it is, but perhaps
>> whatever runs each time I check-in something to my local copy of the
>> repository that checks for indentation and extraneous whitespace could
>> also work for this?
> Couldn't identation and extraneous space be solved by either running after save
> hook in Emacs, or by running emacs in batch mode as a git hook?

Yes, you're both talking about git hooks. A minor disadvantage is that a 
hook needs to be installed, and then a bug in a hook implementation can 
stop you from being able to make a commit (there are overrides, but 
those require more googling).

CI is good because if its visibility: the list of checks on current PRs 
is visible to every newcomer, instead of being buried somewhere near the 
end of the CONTRIBUTE document.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  8:25             ` tomas
  2021-08-27  9:47               ` Tim Cross
@ 2021-08-27 11:49               ` Eli Zaretskii
  2021-08-27 12:03                 ` tomas
  2021-08-27 16:59               ` [External] : " Drew Adams
  2021-08-28  2:01               ` Arthur Miller
  3 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 11:49 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

> Date: Fri, 27 Aug 2021 10:25:08 +0200
> From: <tomas@tuxteam.de>
> 
> > The other interesting trend I'm seeing is with many companies now
> > working to minimise email as part of their internal/external workflows.
> > Many companies are finding it a huge resource sink, cause of unnecessary
> > stress/pressure on staff, source of significant security concerns and a
> > real problem for records management.
> 
> I have watched this process around the 2010s in one company. The
> decision was made at top level (they were convinced by some Microsoft 
> salesperson [1] to switch to Office 365 instead of mail, because...
> mail is old). Today, they still use mail, but have outsourced their
> whole communications infrastructure to Microsoft, GDPR be dammed.

Office 365 includes Outlook, so I don't think you interpret that move
correctly.  It is most probably meant to avoid maintaining email
infrastructure in the company itself.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  9:47               ` Tim Cross
  2021-08-27 10:44                 ` tomas
@ 2021-08-27 11:54                 ` Eli Zaretskii
  2021-08-27 16:59                 ` [External] : " Drew Adams
  2 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 11:54 UTC (permalink / raw)
  To: Tim Cross; +Cc: tomas, emacs-devel

> From: Tim Cross <theophilusx@gmail.com>
> Date: Fri, 27 Aug 2021 19:47:33 +1000
> Cc: emacs-devel@gnu.org
> 
> However, this largely pre-dates the drive to move away from email.
> Email, regardless how it is provided, is a problem for companies. It is
> a major source of security problem, it is a nightmare for records
> management, policy and regulation compliance and a major impediment in
> business workflow automation. While I doubt any company will stop using
> email completely, they are definitely moving way from having it as a key
> technology in their business processes. 

There are no good replacements of email for companies that do business
with remote partners/clients.  On-line meetings aren't a good
solution, especially when issues are confidential and/or you need a
record of what was said.  Security issues with email have been solved
long time ago, so shouldn't prevent anyone from using email.  Where I
work during my day time, email is very much alive and kicking, and we
all have email clients on our smartphones, so we could respond very
quickly to any important developments.  I can tell you that with our
email-based workflows, we run circles around those of our partners and
competitors who don't.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 11:49               ` Eli Zaretskii
@ 2021-08-27 12:03                 ` tomas
  2021-08-28  2:04                   ` Arthur Miller
  0 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-27 12:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

On Fri, Aug 27, 2021 at 02:49:02PM +0300, Eli Zaretskii wrote:

[...]

> > I have watched this process around the 2010s in one company [...]

> Office 365 includes Outlook,

I know. I lived it :)

>                             so I don't think you interpret that move
> correctly.  It is most probably meant to avoid maintaining email
> infrastructure in the company itself.

This was but part of the equation (I had the chance to talk to some
folks next to the decision makers). Actually, this part of the equation
was the more problematic one, because of GDPR. Salespeople promised
this wouldn't be a problem, because "all servers would be in the EU".
Aha :-)

The other was "mail is old, and here we have something *much* better".
This was also the narrative the whole "change management" machinery
was built around, with "planes", "pilots" and "seats" and whatnot.

(Will stop now, because seriously off-topic)

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:26         ` tomas
@ 2021-08-27 12:11           ` dick
  2021-08-27 12:20             ` tomas
  2021-08-27 12:41             ` Eli Zaretskii
  0 siblings, 2 replies; 525+ messages in thread
From: dick @ 2021-08-27 12:11 UTC (permalink / raw)
  To: tomas; +Cc: danflscr, emacs-devel

> On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
>> * Newcomer suggests PR-based workflow citing youth.  Check.

> [rest deleted]

> And this was useful why exactly?

When you've been programming as long as I have, you realize more than ninety
percent of the discussion that takes place before a working draft is
irrelevant.  Robert Burns, who would have made an excellent programmer,
noticed this too.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 12:11           ` dick
@ 2021-08-27 12:20             ` tomas
  2021-08-27 12:41             ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: tomas @ 2021-08-27 12:20 UTC (permalink / raw)
  To: dick; +Cc: danflscr, emacs-devel

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

On Fri, Aug 27, 2021 at 08:11:21AM -0400, dick wrote:
> > On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
> >> * Newcomer suggests PR-based workflow citing youth.  Check.
> 
> > [rest deleted]
> 
> > And this was useful why exactly?
> 
> When you've been programming as long as I have [...]

That was risky, I guess.

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 12:11           ` dick
  2021-08-27 12:20             ` tomas
@ 2021-08-27 12:41             ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 12:41 UTC (permalink / raw)
  To: dick; +Cc: tomas, danflscr, emacs-devel

> From: dick <dick.r.chiang@gmail.com>
> Date: Fri, 27 Aug 2021 08:11:21 -0400
> Cc: danflscr@gmail.com, emacs-devel@gnu.org
> 
> > On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
> >> * Newcomer suggests PR-based workflow citing youth.  Check.
> 
> > [rest deleted]
> 
> > And this was useful why exactly?
> 
> When you've been programming as long as I have, you realize more than ninety
> percent of the discussion that takes place before a working draft is
> irrelevant.  Robert Burns, who would have made an excellent programmer,
> noticed this too.

Do you (or someone else) have come up with a way to recover the 10%
that _is_ relevant without having the other 90%?  If so, please
describe that way, and we will see if we can follow it.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
                   ` (4 preceding siblings ...)
  2021-08-27  0:37 ` Po Lu
@ 2021-08-27 13:35 ` Daniel Martín
  2021-08-27 13:58   ` Eli Zaretskii
  2021-08-27 21:07   ` Stefan Monnier
  2021-08-28  2:59 ` Gitlab Migration Richard Stallman
  6 siblings, 2 replies; 525+ messages in thread
From: Daniel Martín @ 2021-08-27 13:35 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel

Daniel Fleischer <danflscr@gmail.com> writes:

> What areas need attention in order to facilitate the change?
>

Perhaps the people that contribute regularly to Emacs could describe
their workflow in more detail.  For example, things like how they like
to interact with bug reports (if they use the Debbugs Emacs package, for
example), how they search for bugs (if they use the web interface,
search mail locally, or something else), or if they'd like to do code
review from a web UI or doing it via email is a must for them.

I think it's also important to know about the problems and limitations
they face with the current system.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:01   ` john muhl
  2021-08-26 19:08     ` Greg Farough
@ 2021-08-27 13:47     ` Daniel Martín
  2021-08-27 14:57       ` Tassilo Horn
  1 sibling, 1 reply; 525+ messages in thread
From: Daniel Martín @ 2021-08-27 13:47 UTC (permalink / raw)
  To: john muhl; +Cc: emacs-devel

john muhl <email@johnmuhl.mx> writes:

> On Thu, 2021-08-26 at 17:24 +0000, Philip Kaludercic wrote:
>> 
>> I remember Sourceforge being suggested as an alternative to Gitlab,
>
> I think you mean sourcehut <https://sourcehut.org/> (free software)
> not sourceforge <https://sourceforge.net/> (saas).
>
>> but the software is currently still in a beta stage (AFAIR).
>

IIRC, Sourcehut's workflow to send and review patches is still based on
sending mail; it differs from the branch + pull request model of
GitHub/GitLab.

I still see benefits in the way Sourcehut manages and tracks patches,
but I'm not sure it'll help attract new Emacs contributors if the
premise is that people are afraid to contribute because they're not
familiar with email and git patches.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 13:35 ` Daniel Martín
@ 2021-08-27 13:58   ` Eli Zaretskii
  2021-08-27 14:17     ` Daniel Martín
  2021-08-27 21:07   ` Stefan Monnier
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 13:58 UTC (permalink / raw)
  To: Daniel Martín; +Cc: danflscr, emacs-devel

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 15:35:34 +0200
> 
> Daniel Fleischer <danflscr@gmail.com> writes:
> 
> > What areas need attention in order to facilitate the change?
> 
> Perhaps the people that contribute regularly to Emacs could describe
> their workflow in more detail.  For example, things like how they like
> to interact with bug reports (if they use the Debbugs Emacs package, for
> example), how they search for bugs (if they use the web interface,
> search mail locally, or something else), or if they'd like to do code
> review from a web UI or doing it via email is a must for them.

Are you asking about contributors or about the core maintainers?
E.g., you mention interaction with bug reports, but AFAIK contributors
have only one kind of interaction here: when they submit a report.  So
I wonder whether I understand your questions.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 13:58   ` Eli Zaretskii
@ 2021-08-27 14:17     ` Daniel Martín
  2021-08-28  8:11       ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Daniel Martín @ 2021-08-27 14:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: danflscr, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>
> Are you asking about contributors or about the core maintainers?
> E.g., you mention interaction with bug reports, but AFAIK contributors
> have only one kind of interaction here: when they submit a report.  So
> I wonder whether I understand your questions.

The core maintainers: The people that usually check for new bug reports
and act on them, classify them by priority and see if they block a
release, review and commit any patches that are sent to fix the bugs,
etc.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 11:30     ` Eli Zaretskii
@ 2021-08-27 14:33       ` Stefan Monnier
  2021-08-27 14:46         ` Lars Ingebrigtsen
  2021-08-27 21:09         ` Gitlab Migration Dmitry Gutov
  2021-08-27 18:19       ` João Távora
  1 sibling, 2 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-27 14:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Daniel Fleischer, philipk, emacs-devel

> Agreed.  We don't need to force everyone to use a single workflow.
> We should have a platform that supports reasonably well the different
> popular workflows.

AFAIK SourceHut is the only project which explicitly aims to provide
full and convenient support for both web and email control, which makes
it the obvious&natural choice for Emacs, IMO.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:33       ` Stefan Monnier
@ 2021-08-27 14:46         ` Lars Ingebrigtsen
  2021-08-27 14:50           ` Philip Kaludercic
                             ` (2 more replies)
  2021-08-27 21:09         ` Gitlab Migration Dmitry Gutov
  1 sibling, 3 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-27 14:46 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Daniel Fleischer, philipk, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAIK SourceHut is the only project which explicitly aims to provide
> full and convenient support for both web and email control, which makes
> it the obvious&natural choice for Emacs, IMO.

There doesn't seem to be much movement on getting GitLab to support the
features we want, so perhaps we should take a closer look at SourceHut
instead.  Has anybody here done an evaluation of SourceHut to see
whether it'd fit our requirements?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:46         ` Lars Ingebrigtsen
@ 2021-08-27 14:50           ` Philip Kaludercic
  2021-08-27 15:14           ` André A. Gomes
  2021-08-27 15:29           ` Theodor Thornhill
  2 siblings, 0 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-08-27 14:50 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: Eli Zaretskii, Daniel Fleischer, Stefan Monnier, emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> AFAIK SourceHut is the only project which explicitly aims to provide
>> full and convenient support for both web and email control, which makes
>> it the obvious&natural choice for Emacs, IMO.
>
> There doesn't seem to be much movement on getting GitLab to support the
> features we want, so perhaps we should take a closer look at SourceHut
> instead.  Has anybody here done an evaluation of SourceHut to see
> whether it'd fit our requirements?

I have seen this thread:

https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E

It is over a year old, so I am not sure if anything has changed.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 13:47     ` Daniel Martín
@ 2021-08-27 14:57       ` Tassilo Horn
  2021-08-27 15:35         ` Daniel Martín
  0 siblings, 1 reply; 525+ messages in thread
From: Tassilo Horn @ 2021-08-27 14:57 UTC (permalink / raw)
  To: Daniel Martín; +Cc: emacs-devel, john muhl

Daniel Martín <mardani29@yahoo.es> writes:

>> I think you mean sourcehut <https://sourcehut.org/> (free software)
>> not sourceforge <https://sourceforge.net/> (saas).
>
> IIRC, Sourcehut's workflow to send and review patches is still based
> on sending mail; it differs from the branch + pull request model of
> GitHub/GitLab.

That's right.

> I still see benefits in the way Sourcehut manages and tracks patches,

Could you elaborate on that?  I'm using sr.ht for some projects and like
it but haven't seen anything related to tracking and managing patches.
Is there anything beyond "use git send-email to the project mailing
list" from which the maintainer can just "git am"?

Oh, cool, now I've found out that you can filter the list for patches,
mark them as applied or "needs revision" etc.  Thanks for making me
aware!

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:46         ` Lars Ingebrigtsen
  2021-08-27 14:50           ` Philip Kaludercic
@ 2021-08-27 15:14           ` André A. Gomes
  2021-08-27 15:29           ` Theodor Thornhill
  2 siblings, 0 replies; 525+ messages in thread
From: André A. Gomes @ 2021-08-27 15:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: philipk, Eli Zaretskii, Daniel Fleischer, Stefan Monnier, emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There doesn't seem to be much movement on getting GitLab to support the
> features we want, so perhaps we should take a closer look at SourceHut
> instead.  Has anybody here done an evaluation of SourceHut to see
> whether it'd fit our requirements?

I've used SourceHut a bit, and I think it would be suitable for Emacs.
It's email based but it also provides a web UI to centralise all
relevant information.

In fact, sooner or later GNU will replace Savannah and sourcehut has
been referenced as a strong candidate.


--
André A. Gomes
"Free Thought, Free World"



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:46         ` Lars Ingebrigtsen
  2021-08-27 14:50           ` Philip Kaludercic
  2021-08-27 15:14           ` André A. Gomes
@ 2021-08-27 15:29           ` Theodor Thornhill
  2021-08-27 19:08             ` Eli Zaretskii
  2 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-27 15:29 UTC (permalink / raw)
  To: emacs-devel, Lars Ingebrigtsen, Stefan Monnier
  Cc: Eli Zaretskii, Daniel Fleischer, philipk



On 27 August 2021 16:46:22 CEST, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> AFAIK SourceHut is the only project which explicitly aims to provide
>> full and convenient support for both web and email control, which makes
>> it the obvious&natural choice for Emacs, IMO.
>
>There doesn't seem to be much movement on getting GitLab to support the
>features we want, so perhaps we should take a closer look at SourceHut
>instead.  Has anybody here done an evaluation of SourceHut to see
>whether it'd fit our requirements?
>

We actually discussed it on this list with its creator, Drew DeVault last year: 
https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html

Everything seems to be ready, if I understand him correctly. I think he'd be enthusiastic about this.

Theodor



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:57       ` Tassilo Horn
@ 2021-08-27 15:35         ` Daniel Martín
  0 siblings, 0 replies; 525+ messages in thread
From: Daniel Martín @ 2021-08-27 15:35 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-devel, john muhl

Tassilo Horn <tsdh@gnu.org> writes:

>
> Could you elaborate on that?  I'm using sr.ht for some projects and like
> it but haven't seen anything related to tracking and managing patches.
> Is there anything beyond "use git send-email to the project mailing
> list" from which the maintainer can just "git am"?
>
> Oh, cool, now I've found out that you can filter the list for patches,
> mark them as applied or "needs revision" etc.  Thanks for making me
> aware!

Yes, there's some tagging and classification on top of plain mailing
list patches.  Another interesting feature of SourceHut is its
continuous integration support for patches. Core maintainers, before
merging a patch, could easily see if it breaks something in a rare
platform or if it generates new warnings.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-27  8:25             ` tomas
  2021-08-27  9:47               ` Tim Cross
  2021-08-27 11:49               ` Eli Zaretskii
@ 2021-08-27 16:59               ` Drew Adams
  2021-08-27 17:08                 ` tomas
  2021-08-28  2:01               ` Arthur Miller
  3 siblings, 1 reply; 525+ messages in thread
From: Drew Adams @ 2021-08-27 16:59 UTC (permalink / raw)
  To: tomas, emacs-devel

> > Yep, that mirrors what I'm seeing as well. Many younger users really use
> > it primarily to provide a unique identifier (login) and for when they
> > have to deal with institutions that don't provide other alternatives.
> 
> I think part of the rush is nudge pressure applied by the Big Ones.
> It's not possible to monetise mail in the same way as it is possible
> to do with whatsapp, tiktok, twitter and the uncountable more or less
> "secure" messengers popping up here and there.

+1.

Email is less of an Only-Mine-All-Mine!!! mine for
surveillance capitalism to mine.

And being still relatively new, the "instant
notification" of Slack etc. seems handy.  Wait till
there's as much incoming traffic for you there, as
there is your email inbox.

Yeah, you can turn off notifications, but they seem
to be touted as one of the killer-app features of
"always-on" Slacking (much appreciated by mgrs, in
particular).

> The nice thing about those communications platforms (nice from the
> perspective of the venture capitalist) is that there's no separation
> of platform and UI, so they get direct control of the user's perception.
> 
> I opt out of that. Count me in whenever there is a platform which
> separates transport and clients the way mail does and has at least
> some choice of client applications with a perspective of diversity.

+1.

> > The other interesting trend I'm seeing is with many companies now
> > working to minimise email as part of their internal/external workflows.
> > Many companies are finding it a huge resource sink, cause of unnecessary
> > stress/pressure on staff, source of significant security concerns and a
> > real problem for records management.
> 
> I have watched this process around the 2010s in one company. The
> decision was made at top level (they were convinced by some Microsoft
> salesperson [1] to switch to Office 365 instead of mail, because...
> mail is old). Today, they still use mail, but have outsourced their
> whole communications infrastructure to Microsoft, GDPR be dammed.
> 
> The resource sink, stress and pressure stemmed rather from that
> change, for those who had to use that "new" platform (not to
> talk about staff layoffs for the old sysadmins, but I disgress).
> 
> Those having taken the decisions didn't have to use O365, they
> have secretaries. For them, it was success.
> 
> This may sound like an off-topic rant, but I'm serious. Not all
> of this "mail is old" meme is for real. Some of it is propaganda
> (I emphasise: /some/ of it). So we should take each critique
> and address it one by one.
> 
> To put it in other words: I won't pay a wholesale-ish "mail is
> old" argument. I want to have more solid stuff.

Agree.

^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-27  9:47               ` Tim Cross
  2021-08-27 10:44                 ` tomas
  2021-08-27 11:54                 ` Eli Zaretskii
@ 2021-08-27 16:59                 ` Drew Adams
  2 siblings, 0 replies; 525+ messages in thread
From: Drew Adams @ 2021-08-27 16:59 UTC (permalink / raw)
  To: Tim Cross, tomas; +Cc: emacs-devel

Shiny new toy syndrome.  Even if not really
so new.

(Not at all saying you're infected, Tim.
Just saying it's out there, endemic here &
there, if not yet pandemic.)

> The problem with that argument is that it doesn't explain the behaviour
> of young adults and teenagers. Nobody has 'nudged' them to move away
> from email - they were never into it. It simply isn't a communication
> medium they are interested in. For them, it is about IM, instagram,
> tiktok etc. Some of it is because of marketing, a lot of it is because
> of peer influences. Regardless, email is of no interest to them.

They're already pwned, lock, stock, and barrel.

Even seemingly self-determined "peer influence"
is influenced - by the same pwners.  That's what
they do.

And the pwnees _are_ (actively) "nudged" - to
stay pwned.  They're even led to proudly show
off their guilded, fools-gold ankle bracelets.

> ... this largely pre-dates the drive to move away from email.
> Email, regardless how it is provided, is a problem for companies. It is
> a major source of security problem, it is a nightmare for records
> management, policy and regulation compliance and a major impediment in
> business workflow automation. While I doubt any company will stop using
> email completely, they are definitely moving way from having it as a key
> technology in their business processes.

Sure.  Compliance is a headache.  History and
its footprints are a bother.  Being able to go
back and see who did and said what is, well,
something that some would rather evade/avoid.

> The problems with email for business are real. While lots of companies
> are pushing their alternative solutions for various reasons, it doesn't
> remove the reality that it fails for business on many levels.

That just means that email isn't the answer
to every problem.  The Message is not The
Messiah.

> the key point to note is that I don't think anyone is saying we need to
> get rid of the email based stuff we currently have - what people are
> asking for is to have an alternative interface..., not instead of.

Additional interfaces/UXes, yes.

> Arguments about one being better than the other are pointless

Pointing out relevant, relative advantages
isn't pointless.  Not if there's a chance of
that "instead of".

And even if there's no such chance, it's not
pointless because it can affect design of
alternatives to fit together with an email
interface.

> What people are asking for is support for a
> broader set of preferences.

I think so, and I hope for that to happen.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-27 16:59               ` [External] : " Drew Adams
@ 2021-08-27 17:08                 ` tomas
  2021-08-29  3:01                   ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-27 17:08 UTC (permalink / raw)
  To: emacs-devel

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

On Fri, Aug 27, 2021 at 04:59:32PM +0000, Drew Adams wrote:
> > > Yep, that mirrors what I'm seeing as well. Many younger users really use
> > > it primarily to provide a unique identifier (login) and for when they
> > > have to deal with institutions that don't provide other alternatives.
> > 
> > I think part of the rush is nudge pressure applied by the Big Ones.
> > It's not possible to monetise mail [...]

[...]

> Email is less of an Only-Mine-All-Mine!!! mine for
> surveillance capitalism to mine.
> 
> And being still relatively new, the "instant
> notification" of Slack etc. seems handy.  Wait till
> there's as much incoming traffic for you there, as
> there is your email inbox.

Heh. You also a Slack victim? When they introduced it at
$COMPANY (before O365 took all), I decided that it violates
the Convention of Geneva.

Having a browser open all the time, OK. But having the
browser bouncing up'n down while I try to concentrate
on a database schema... that's cruel ;-)

(I don't work for $COMPANY anymore).

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
                     ` (5 preceding siblings ...)
  2021-08-27  7:00   ` Daniel Fleischer
@ 2021-08-27 18:02   ` Augusto Stoffel
  2021-08-28  2:59   ` Richard Stallman
  7 siblings, 0 replies; 525+ messages in thread
From: Augusto Stoffel @ 2021-08-27 18:02 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Daniel Fleischer, emacs-devel

On Thu, 26 Aug 2021 at 17:24, Philip Kaludercic <philipk@posteo.net> wrote:

> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.

To quote Rich Hickey, a pull request is not a value.

A patch is just a value, so no wonder it's easier to make a patch reach
an Emacs maintainer than to maneuver an online collaboration platform
into some state.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 11:30     ` Eli Zaretskii
  2021-08-27 14:33       ` Stefan Monnier
@ 2021-08-27 18:19       ` João Távora
  2021-08-28  2:07         ` Arthur Miller
  2021-08-29  3:01         ` Richard Stallman
  1 sibling, 2 replies; 525+ messages in thread
From: João Távora @ 2021-08-27 18:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Philip K., Daniel Fleischer, emacs-devel

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

On Fri, Aug 27, 2021, 12:31 Eli Zaretskii <eliz@gnu.org> wrote:

> Agreed.  We don't need to force everyone to use a single workflow.  We
> should have a platform that supports reasonably well the different
> popular workflows.
>

I wish this point was stressed more often. Git, to which we've switched
reasonably recently after some pain, accommodates many many workflows. We
should embrace that!!

E.g. if browser living people want to make PRs to an intermediate repo on
GitHub, they can today! And then once they're reasonably stable and agreed
upon, some email wizard (really, can be me, even though I'm not really a
wizard) can push them to main repo, and even adjust a commit message or
two. Git provides lots of commands for that,. I'm happy to explain and
document them, though I doubt I'm the only such expert here.

The main question is where the discussion happens: it has to be email,
period. And right now it's debbugs and emacs-devel. And yes I know that
GitHub/gitlab do pretty links automatically between web UI parts, but how
is that so different from sending email where you say you have a public
branch with x commits here or there?

My two cents,
João

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 15:29           ` Theodor Thornhill
@ 2021-08-27 19:08             ` Eli Zaretskii
  2021-08-27 19:38               ` Theodor Thornhill
  2021-08-27 20:45               ` GitLab feature request compared with SourceHut (was: Re: Gitlab Migration) Sean Whitton
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 19:08 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, larsi, danflscr, monnier, emacs-devel

> Date: Fri, 27 Aug 2021 17:29:46 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>  philipk@posteo.net
> 
> >There doesn't seem to be much movement on getting GitLab to support the
> >features we want, so perhaps we should take a closer look at SourceHut
> >instead.  Has anybody here done an evaluation of SourceHut to see
> >whether it'd fit our requirements?
> >
> 
> We actually discussed it on this list with its creator, Drew DeVault last year: 
> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html

That was almost a year ago, and the discussion is thin on actual
details.  Support for email-based workflow is a good start, and is one
of the main requirements, but what about the GitLab/Github-like
features? if they are missing or incomplete, we will be trading
debbugs for something that is basically the same beast in a different
wrapping.  And what about the other requirements we collected and
documented in the GitLab issue about this?

So, like Lars, I think it would help if someone could post an
evaluation of SourceHut vs what we'd like to see, using the GitLab
issue as the baseline.

TIA



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 19:08             ` Eli Zaretskii
@ 2021-08-27 19:38               ` Theodor Thornhill
  2021-08-27 20:07                 ` Eli Zaretskii
  2021-08-27 20:45               ` GitLab feature request compared with SourceHut (was: Re: Gitlab Migration) Sean Whitton
  1 sibling, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-27 19:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, larsi, monnier, danflscr, philipk, sir

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 27 Aug 2021 17:29:46 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>>  philipk@posteo.net
>> 
>> >There doesn't seem to be much movement on getting GitLab to support the
>> >features we want, so perhaps we should take a closer look at SourceHut
>> >instead.  Has anybody here done an evaluation of SourceHut to see
>> >whether it'd fit our requirements?
>> >
>> 
>> We actually discussed it on this list with its creator, Drew DeVault last year: 
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>
> That was almost a year ago, and the discussion is thin on actual
> details.  Support for email-based workflow is a good start, and is one
> of the main requirements, but what about the GitLab/Github-like
> features? if they are missing or incomplete, we will be trading
> debbugs for something that is basically the same beast in a different
> wrapping.  And what about the other requirements we collected and
> documented in the GitLab issue about this?
>

It seems like Sourcehut supports everything requested, but I might be
missing something, of course.  In particular the CI is very nice and
simple, at least for the hosted version at https://sr.ht.  It also
supports running without javascript at all, so the libreJS debate should
be settled right there. Instead of me speaking on sourcehuts behalf,
with which I have no affiliation outside of being a happy customer
myself, I'll ping the creator.

@drew, should I or someone else create an issue over at sourcehut about
this or do you want to chime in here?  (apologies if contacting you this
way is inappropriate)


> So, like Lars, I think it would help if someone could post an
> evaluation of SourceHut vs what we'd like to see, using the GitLab
> issue as the baseline.
>
> TIA


Hope this helps,
Theodor



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 19:38               ` Theodor Thornhill
@ 2021-08-27 20:07                 ` Eli Zaretskii
  2021-08-27 20:58                   ` Philip Kaludercic
  2021-08-27 21:04                   ` Theodor Thornhill
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-27 20:07 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, danflscr, emacs-devel, monnier, larsi, sir

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
> Date: Fri, 27 Aug 2021 21:38:43 +0200
> 
> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
> >
> > That was almost a year ago, and the discussion is thin on actual
> > details.  Support for email-based workflow is a good start, and is one
> > of the main requirements, but what about the GitLab/Github-like
> > features? if they are missing or incomplete, we will be trading
> > debbugs for something that is basically the same beast in a different
> > wrapping.  And what about the other requirements we collected and
> > documented in the GitLab issue about this?
> >
> 
> It seems like Sourcehut supports everything requested, but I might be
> missing something, of course.  In particular the CI is very nice and
> simple, at least for the hosted version at https://sr.ht.  It also
> supports running without javascript at all, so the libreJS debate should
> be settled right there. Instead of me speaking on sourcehuts behalf,
> with which I have no affiliation outside of being a happy customer
> myself, I'll ping the creator.

Would it be possible to have a more detailed review, like short
description of what is available for each of the requirements in the
GitLab issue?  That should give us a good idea of how close we are to
the goal.

I tried to find answers to those questions myself, but there doesn't
seem to be any detailed documentation that describes the setup and
usage from the routine user POV (or maybe I missed it?).  I did find a
heads-up that "from the beta onwards, unpaid accounts will be limited
to read-only access to their own projects", so I wonder what that
means for us.  It also says that "web-based workflow for submitting
and reviewing patches" is still under development.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* GitLab feature request compared with SourceHut (was: Re: Gitlab Migration)
  2021-08-27 19:08             ` Eli Zaretskii
  2021-08-27 19:38               ` Theodor Thornhill
@ 2021-08-27 20:45               ` Sean Whitton
  2021-08-28  7:18                 ` Tassilo Horn
  1 sibling, 1 reply; 525+ messages in thread
From: Sean Whitton @ 2021-08-27 20:45 UTC (permalink / raw)
  To: Eli Zaretskii, Theodor Thornhill
  Cc: philipk, danflscr, emacs-devel, monnier, larsi, sir

Hello,

On Fri 27 Aug 2021 at 10:08PM +03, Eli Zaretskii wrote:

>> Date: Fri, 27 Aug 2021 17:29:46 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>>  philipk@posteo.net
>>
>> >There doesn't seem to be much movement on getting GitLab to support the
>> >features we want, so perhaps we should take a closer look at SourceHut
>> >instead.  Has anybody here done an evaluation of SourceHut to see
>> >whether it'd fit our requirements?
>> >
>>
>> We actually discussed it on this list with its creator, Drew DeVault last year:
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>
> That was almost a year ago, and the discussion is thin on actual
> details.  Support for email-based workflow is a good start, and is one
> of the main requirements, but what about the GitLab/Github-like
> features? if they are missing or incomplete, we will be trading
> debbugs for something that is basically the same beast in a different
> wrapping.  And what about the other requirements we collected and
> documented in the GitLab issue about this?

For reference, the GitLab issue:
<https://gitlab.com/gitlab-org/gitlab/-/issues/28152>

> So, like Lars, I think it would help if someone could post an
> evaluation of SourceHut vs what we'd like to see, using the GitLab
> issue as the baseline.

Using the headers in the GitLab issue:

E-MAIL WORKFLOW

This is a given.  SourceHut is all about this.

Something to emphasise is that because SourceHut is e-mail first, rather
than a web platform with e-mail access tacked on, you don't have to
worry about how web forges can do things like ignoring everything in the
message after the first quoted portion, for example.  You don't find
yourself going on the website after replying by e-mail just to check
your text made it through.

REDUCE E-MAIL NOISE

There isn't much granularity regarding notifications, AFAICT.

SUBMITTING PATCHES BY E-MAIL

There's a web interface to prepare patch sets designed to be familiar
to web forge users.

OFFLINE REVIEW

Yes.

REVIEWING PATCHES BY E-MAIL

Yes.

MERGE REQUEST CREATION

Yes.

CODE SHOULD BE ACCOMPANIED BY DOCUMENTATION

Could be done with CI, like GitLab.

FORMATTING CODE COMMITS

Could be done with CI, like GitLab.

DIFF MAILING LIST

No special features for this, I believe.  You'd need a bot.

TRACEABILITY OF MERGE REQUESTS

The mailing list web interface keeps track of the status of series and
tags them "proposed", "applied" etc. and this is searchable.

CONTINUOUS INTEGRATION

Yes.

CLOSELY INTEGRATED BUGTRACKER

Looks a bit manual atm, but a big step up from debbugs because there is
both e-mail control and clickable buttons.

SPELLING & GRAMMAR CHECKING

Could be done with CI.

COPYRIGHT ASSIGNMENTS

Could be done with CI.

LICENSING

Yes.

INTEGRATION WITH SAVANNAH

SourceHut can currently use PAM users, so a Savannah/LDAP integration
along the same lines ought to be doable.

EMACS FRONTEND FOR BUG TRACKER

Doesn't exist yet :)

BUG REPORTING

Filing bugs and starting mailing list threads are both just a matter of
sending e-mails, so report-emacs-bug could do it.

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 20:07                 ` Eli Zaretskii
@ 2021-08-27 20:58                   ` Philip Kaludercic
  2021-08-27 21:06                     ` Sean Whitton
  2021-08-28  8:00                     ` Eli Zaretskii
  2021-08-27 21:04                   ` Theodor Thornhill
  1 sibling, 2 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-08-27 20:58 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: danflscr, Theodor Thornhill, emacs-devel, monnier, larsi, sir

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
>> Date: Fri, 27 Aug 2021 21:38:43 +0200
>> 
>> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>> >
>> > That was almost a year ago, and the discussion is thin on actual
>> > details.  Support for email-based workflow is a good start, and is one
>> > of the main requirements, but what about the GitLab/Github-like
>> > features? if they are missing or incomplete, we will be trading
>> > debbugs for something that is basically the same beast in a different
>> > wrapping.  And what about the other requirements we collected and
>> > documented in the GitLab issue about this?
>> >
>> 
>> It seems like Sourcehut supports everything requested, but I might be
>> missing something, of course.  In particular the CI is very nice and
>> simple, at least for the hosted version at https://sr.ht.  It also
>> supports running without javascript at all, so the libreJS debate should
>> be settled right there. Instead of me speaking on sourcehuts behalf,
>> with which I have no affiliation outside of being a happy customer
>> myself, I'll ping the creator.
>
> Would it be possible to have a more detailed review, like short
> description of what is available for each of the requirements in the
> GitLab issue?  That should give us a good idea of how close we are to
> the goal.

Here is my take:

+ Email workflow

  Is supported as a first-class interaction method

+ Reduce email noise

  The mailing lists are just mailing lists, from
  what I know the only "spam" might be CI responding with the results of
  a test

+ Submitting patches by email

  Is supported as part of the email workflow

+ Offline review

  Same as above

+ Reviewing patches by email

  Ditto, and the comments are rendered properly in the web UI.

* Merge request creation

  Not sure if this is applicable, you'd usually just send a patch and
  not create a format "merge request".

* Code should be accompanied by documentation

  Here too I cannot say for sure, but I can imagine integrating checkdoc
  into a CI that automatically warns a patch-submitter if something
  isn't documented properly.

* Formatting code commits

  Same as above.

* Traceability of Merge Requests

  Again, merge requests are not formal but just a message on the mailing
  list, usually generated by git send-email. (There might be an issue
  here if users just attach patches as they do now.)

+ Continuous integration

  Is given

? Closely integrated bugtracker

  I haven't used "todo" (the issue tracker,
  https://man.sr.ht/todo.sr.ht/) enough to really comment on this. My
  general understanding is that this, integration between the different
  components, is one of the things that remain in need of improvement
  before the project leaves the beta stage

* Spell & grammar checking

  Again, could be done with CIs. Assuming one has a grammar checker.

- Branch rules

  I don't know of any mechanism to limit access to branches.

* Copyright assignments

  CI should be able to handle this.

+ Licensing

  Yes!

- Integration with savannah

  Is not implemented, but the question is if the existing infrastructure
  should be extended or replaced.

- Integration with debbugs

  Same as above.

- Emacs frontend for bug tracker

  There is no package for sourcehut comparable to debbugs, but it
  shouldn't be hard to implement considering that.
  
+ Bug reporting

  The mailing list should be able to handle bugs M-x report-emacs-bug.
  
> I tried to find answers to those questions myself, but there doesn't
> seem to be any detailed documentation that describes the setup and
> usage from the routine user POV (or maybe I missed it?).  I did find a
> heads-up that "from the beta onwards, unpaid accounts will be limited
> to read-only access to their own projects", so I wonder what that
> means for us.  It also says that "web-based workflow for submitting
> and reviewing patches" is still under development.

It shouldn't mean anything, if GNU decides to host their own
instance. Otherwise, every project member would have to play to have an
account, but I assume mailing list contributors could continue accessing
the mailing list without any issue.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 20:07                 ` Eli Zaretskii
  2021-08-27 20:58                   ` Philip Kaludercic
@ 2021-08-27 21:04                   ` Theodor Thornhill
  2021-08-28  7:55                     ` Eli Zaretskii
  2021-08-28 15:24                     ` Lars Ingebrigtsen
  1 sibling, 2 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-27 21:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, larsi, monnier, danflscr, philipk, sir

Eli Zaretskii <eliz@gnu.org> writes:


[...]

>
> Would it be possible to have a more detailed review, like short
> description of what is available for each of the requirements in the
> GitLab issue?  That should give us a good idea of how close we are to
> the goal.
>

Sure, I can try.  At the minimum, it can serve as a starting point from
which Drew can correct all my mistakes when he chimes in.  Firstly, I'll
say that it in general offers a similar workflow to what emacs
developers already use.  It also has an explicit goal of not being too
GitHub/GitLab-like, where pull requests are the default way to
contribute.  However, there are some key differences. You don't need a
user account to use it, though that gives you some benefits like cloning
repos etc.  It is and always will be (I think) emailbased rather than
forms on the web.  That means using `git am` and friends to push and
pull the code.

About payment - all users should be able to report bugs when it hits
beta.  The paid features is for the cloning and personal repo hosting, I
think.  Also not sure if this applies when sourcehut is self hosted.

As for the specific points in the gitlab issue, let me make an effort:

* Email workflow
This is a given.  Patches and discussions are all first class citizens,
meaning that it is all backed by email. You can open, close, adjust and
respond to issues using email.

** Submitting patches by email.
It is possible to send patches using a web interface.  It works by using
the `prepare a patchset` button on your own clone.  So the process
is usually:
  - clone the repo
  - pull it locally
  - do the work
  - push the work
  - use the `prepare a patchset` button or `git format-patch`

It is then sent to the respective mailing list

** Offline review
An issue (if not already subscribed to all) can be subscribed to your
own email and be sent to you.  The whole thing or parts of it can be
downloaded as an mbox.

** Reviewing by email
You can use inline comments [1]

** Merge request creation
Honestly I don't really understand this one...

* Code should be accompanied by documentation

This seems trivial, and can be done using the CI on patch submission
running a job, if I understand that point correctly?

* Formatting code commits
 Same as above

* Diff mailing list
This I don't know

* Traceability of Merge Requests

There is at least a basic web search available on the web client for
this, but seeing how the only repo I maintain with actual contributors I
maintain is on GitHub I don't have much first hand experience here.

* Continuous integration
This is one of sourcehuts strong points, as I see it. Jobs can be run on
patch submission and on commits, and is also inspectable through ssh
should something break.  Arbitrary stuff can be done here.

* Closely integrated bugtracker
automated tasks for patch application and status updates exist here

...

There seems to be some more points here that could be covered by CI, so
I'll jump a little
...

* Licensing
No js is needed
Captcha is not used
GNU criteria for ethics I cannot say anything about. Though it would
surprise me if it didn't score well.

* Integration with savannah
I can't say anything about this

* Integration with debbugs
Seeing how both use mbox this should be trivial to do

* Bug reporting
`report-emacs-bug` can still be used, as well as clicking in the web
ui. This is where I'm not sure about not using email.  I think you still
need to mail the bug, opened by a mailto:

I hope this helps a little.

--
Theodor

[1]: https://lists.sr.ht/~technomancy/fennel/patches/24386



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 20:58                   ` Philip Kaludercic
@ 2021-08-27 21:06                     ` Sean Whitton
  2021-08-28  8:00                     ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Sean Whitton @ 2021-08-27 21:06 UTC (permalink / raw)
  To: Philip Kaludercic, Eli Zaretskii
  Cc: danflscr, Theodor Thornhill, emacs-devel, monnier, larsi, sir

Hello,

On Fri 27 Aug 2021 at 08:58PM GMT, Philip Kaludercic wrote:

> It shouldn't mean anything, if GNU decides to host their own
> instance. Otherwise, every project member would have to play to have an
> account, but I assume mailing list contributors could continue accessing
> the mailing list without any issue.

Regarding the hosted offering at sr.ht, contributors don't need to pay,
only the project owners.

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 13:35 ` Daniel Martín
  2021-08-27 13:58   ` Eli Zaretskii
@ 2021-08-27 21:07   ` Stefan Monnier
  2021-08-28  2:31     ` Arthur Miller
                       ` (2 more replies)
  1 sibling, 3 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-27 21:07 UTC (permalink / raw)
  To: Daniel Martín; +Cc: Daniel Fleischer, emacs-devel

> Perhaps the people that contribute regularly to Emacs could describe
> their workflow in more detail.  For example, things like how they like
> to interact with bug reports (if they use the Debbugs Emacs package, for
> example),

FWIW, here are my main criticisms of debbugs for my own personal use:

- Can't search the database when I'm offline.
  I really wish the database was stored in Git, so I could easily have
  a clone of it.  This said, compared to other issue tracking systems,
  the fact that it works over email makes it at least partly usable
  offline, which is a big plus.

- No notion of "subscription" to a bug, so replies will sometimes fail
  to reach me.

- The notion of "archived" bugs is a pain in the rear when you send
  a new message and the message just bounces back with "the bug is
  archived".
  Either get rid of it, or automatically unarchive bugs when a new reply
  is received, or something (e.g. ask for a confirmation message to
  unarchive the bug and add the already sent message), but the current
  way this is handled is *really* poor.

- I find it a big difficult to classify bugs.  I'm not sure exactly what
  I'd like, and maybe some of it can be done via tags and other things
  already, but I think I'd like it if bugs could be "assigned" to persons
  and/or to files and/or to "subsystems", and maybe even combine this
  with ways to describe relationships between those things (so the
  search tools can known that a given file belongs to a particular
  subsystem, for example).

The poor web UI is of course another criticism but it mostly doesn't
affect me.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:33       ` Stefan Monnier
  2021-08-27 14:46         ` Lars Ingebrigtsen
@ 2021-08-27 21:09         ` Dmitry Gutov
  2021-08-27 21:17           ` Theodor Thornhill
  2021-08-28  6:00           ` Eli Zaretskii
  1 sibling, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-27 21:09 UTC (permalink / raw)
  To: Stefan Monnier, Eli Zaretskii; +Cc: philipk, Daniel Fleischer, emacs-devel

On 27.08.2021 17:33, Stefan Monnier wrote:
>> Agreed.  We don't need to force everyone to use a single workflow.
>> We should have a platform that supports reasonably well the different
>> popular workflows.
> 
> AFAIK SourceHut is the only project which explicitly aims to provide
> full and convenient support for both web and email control, which makes
> it the obvious&natural choice for Emacs, IMO.

 From what I have seen of it, it's email-first, and far from "full and 
convenient support for ... web".

For example, those quality-of-life features that Gitlab has in the 
browser which I previously figured would be difficult to translate  to 
email (the code review workflow, with inline comments and updates from 
the branch; automatically updated CI indicators and links to builds; 
editing of messages) are predictably absent.

Of course, it should still be a significant step forward compared to the 
current situation.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:09         ` Gitlab Migration Dmitry Gutov
@ 2021-08-27 21:17           ` Theodor Thornhill
  2021-08-27 21:35             ` Dmitry Gutov
  2021-08-28  6:01             ` Eli Zaretskii
  2021-08-28  6:00           ` Eli Zaretskii
  1 sibling, 2 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-27 21:17 UTC (permalink / raw)
  To: Dmitry Gutov, Stefan Monnier, Eli Zaretskii
  Cc: philipk, Daniel Fleischer, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 27.08.2021 17:33, Stefan Monnier wrote:
>>> Agreed.  We don't need to force everyone to use a single workflow.
>>> We should have a platform that supports reasonably well the different
>>> popular workflows.
>> 
>> AFAIK SourceHut is the only project which explicitly aims to provide
>> full and convenient support for both web and email control, which makes
>> it the obvious&natural choice for Emacs, IMO.
>
>  From what I have seen of it, it's email-first, and far from "full and 
> convenient support for ... web".
>
> For example, those quality-of-life features that Gitlab has in the 
> browser which I previously figured would be difficult to translate  to 
> email (the code review workflow, with inline comments and updates from 
> the branch; automatically updated CI indicators and links to builds; 
> editing of messages) are predictably absent.

This isn't really true though.  There definitely are links to builds and
inline comments.  Though I agree on parts of this.  One missing thing as
I see it is the updated patch. You need to find the latest patches, and
it won't update as in GitHub when you add another "oops" commit.

>
> Of course, it should still be a significant step forward compared to the 
> current situation.

Yeah.  One might also think that some contributions could trickle down
to sourcehut itself when emacs workflow settles, so the "github way" of
contributing could get a little love?

Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:17           ` Theodor Thornhill
@ 2021-08-27 21:35             ` Dmitry Gutov
  2021-08-27 21:44               ` Theodor Thornhill
  2021-08-28  6:01             ` Eli Zaretskii
  1 sibling, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-27 21:35 UTC (permalink / raw)
  To: Theodor Thornhill, Stefan Monnier, Eli Zaretskii
  Cc: philipk, Daniel Fleischer, emacs-devel

On 28.08.2021 00:17, Theodor Thornhill wrote:

>>   From what I have seen of it, it's email-first, and far from "full and
>> convenient support for ... web".
>>
>> For example, those quality-of-life features that Gitlab has in the
>> browser which I previously figured would be difficult to translate  to
>> email (the code review workflow, with inline comments and updates from
>> the branch; automatically updated CI indicators and links to builds;
>> editing of messages) are predictably absent.
> 
> This isn't really true though.

It seems substantially true.

> There definitely are links to builds and

There's no such examples on the home page (and it does have a link to a 
page supposed to resemble a code review). If you have a better link, 
please share.

> inline comments.

Inline comments like quoting parts of an attached patch inline in an 
email, which we've been doing for decades in emacs-devel? That's not 
even close to a dedicated code review UI.

> Though I agree on parts of this.  One missing thing as
> I see it is the updated patch. You need to find the latest patches, and
> it won't update as in GitHub when you add another "oops" commit.

The review UI would need to be tied to a particular branch, instead of 
some file attachments. And happen not in a email client, but either in a 
browser, or perhaps some re-implementation of the same UI inside Emacs.

>> Of course, it should still be a significant step forward compared to the
>> current situation.
> 
> Yeah.  One might also think that some contributions could trickle down
> to sourcehut itself when emacs workflow settles, so the "github way" of
> contributing could get a little love?

I doubt that: since the system is email-first, it would likely be hard 
to promote/upstream features that don't translate well to email. Even if 
someone writes an Emacs UI for them. Does Drew use Emacs?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:35             ` Dmitry Gutov
@ 2021-08-27 21:44               ` Theodor Thornhill
  2021-08-27 22:42                 ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-27 21:44 UTC (permalink / raw)
  To: Dmitry Gutov, Stefan Monnier, Eli Zaretskii
  Cc: philipk, Daniel Fleischer, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 28.08.2021 00:17, Theodor Thornhill wrote:
>
>>>   From what I have seen of it, it's email-first, and far from "full and
>>> convenient support for ... web".
>>>
>>> For example, those quality-of-life features that Gitlab has in the
>>> browser which I previously figured would be difficult to translate  to
>>> email (the code review workflow, with inline comments and updates from
>>> the branch; automatically updated CI indicators and links to builds;
>>> editing of messages) are predictably absent.
>> 
>> This isn't really true though.
>
> It seems substantially true.
>
>> There definitely are links to builds and
>
> There's no such examples on the home page (and it does have a link to a 
> page supposed to resemble a code review). If you have a better link, 
> please share.
>

https://lists.sr.ht/~technomancy/fennel/patches/24386

This shows both a build that succeeded and an inline comment.  More
complicated stuff is likely still missing, but this seems to address
part of what you were referring to, doesn't it?  There's also examples
where faling builds sends out notifications etc.  I can try to find some
of those, but that will be shooting in the dark until I find one...

>> inline comments.
>
> Inline comments like quoting parts of an attached patch inline in an 
> email, which we've been doing for decades in emacs-devel? That's not 
> even close to a dedicated code review UI.
>
>> Though I agree on parts of this.  One missing thing as
>> I see it is the updated patch. You need to find the latest patches, and
>> it won't update as in GitHub when you add another "oops" commit.
>
> The review UI would need to be tied to a particular branch, instead of 
> some file attachments. And happen not in a email client, but either in a 
> browser, or perhaps some re-implementation of the same UI inside Emacs.
>

Yeah, I agree this is missing, at least if we're not willing to accept
that this might not be the number one thing to need before migrating.


>>> Of course, it should still be a significant step forward compared to the
>>> current situation.
>> 
>> Yeah.  One might also think that some contributions could trickle down
>> to sourcehut itself when emacs workflow settles, so the "github way" of
>> contributing could get a little love?
>
> I doubt that: since the system is email-first, it would likely be hard 
> to promote/upstream features that don't translate well to email. Even if 
> someone writes an Emacs UI for them. Does Drew use Emacs?

You might be correct about this.  No, he is a vim user, and seems a
little negative towards emacs, as far as I can tell.

Theodor



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:44               ` Theodor Thornhill
@ 2021-08-27 22:42                 ` Dmitry Gutov
  0 siblings, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-27 22:42 UTC (permalink / raw)
  To: Theodor Thornhill, Stefan Monnier, Eli Zaretskii
  Cc: philipk, Daniel Fleischer, emacs-devel

On 28.08.2021 00:44, Theodor Thornhill wrote:

>> There's no such examples on the home page (and it does have a link to a
>> page supposed to resemble a code review). If you have a better link,
>> please share.
>>
> 
> https://lists.sr.ht/~technomancy/fennel/patches/24386
> 
> This shows both a build that succeeded and an inline comment.  More
> complicated stuff is likely still missing, but this seems to address
> part of what you were referring to, doesn't it?

Finally found it. Yeah, that looks good. Hope others will have an easier 
time noticing it.

> There's also examples
> where faling builds sends out notifications etc.  I can try to find some
> of those, but that will be shooting in the dark until I find one...

I think I'll take you at your word here. And yeah, notifications are 
important.

>> The review UI would need to be tied to a particular branch, instead of
>> some file attachments. And happen not in a email client, but either in a
>> browser, or perhaps some re-implementation of the same UI inside Emacs.
>>
> 
> Yeah, I agree this is missing, at least if we're not willing to accept
> that this might not be the number one thing to need before migrating.

I think a more important blocker is the bug tracker integration 
(sourcehut has something called "todo", right?). I hear it's still 
work-in-progress, though maybe that info is outdated?

If after migration we're still using Debbugs, that's pretty much going 
to nullify any advantages, in my eyes.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:27       ` Dmitry Gutov
  2021-08-26 19:33         ` Eli Zaretskii
@ 2021-08-27 22:50         ` Yuchen Pei
  2021-08-28  4:57           ` Werner LEMBERG
  1 sibling, 1 reply; 525+ messages in thread
From: Yuchen Pei @ 2021-08-27 22:50 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Eli Zaretskii, danflscr, emacs-devel

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


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 19:56, Eli Zaretskii wrote:
>> We could prioritize the requirements, perhaps, and consider 
>> switching
>> after some critical mass of them is done.
>
> Sounds good.
>
> The two "external" items (reCAPTCHA and LibreJS) might be hard
> requirements from RMS, though.

Well, they are problematic because reCAPTCHA is nonfree, and the 
mandatory javascript programs have no license information that 
comes with them (hence not librejs-compliant).

As others have mentioned there is an ongoing effort in evaluating 
forges mainly based on free software values:

- https://www.gnu.org/software/repo-criteria.en.html
- https://lists.gnu.org/mailman/listinfo/repo-criteria-discuss

-- 
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
           <https://ypei.me/assets/ypei-pubkey.txt>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:50     ` Daniel Fleischer
  2021-08-27 11:20       ` Eli Zaretskii
@ 2021-08-27 23:13       ` Yuchen Pei
  1 sibling, 0 replies; 525+ messages in thread
From: Yuchen Pei @ 2021-08-27 23:13 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel, john muhl

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


Daniel Fleischer <danflscr@gmail.com> writes:

> john muhl [2021-08-26 Thu 14:13]  *wrote*:
>
>> On Thu, 2021-08-26 at 14:51 -0400, Stefan Monnier wrote:
>>> 
>>> The last I heard from this is that some software was 
>>> considered and
>>> there was a web page summarizing the status, but that was 
>>> maybe 2
>>> years ago and I can't find that page any more
>>
>> maybe one on these:
>> <https://libreplanet.org/wiki/FSF_2020_forge_evaluation>
>> <https://www.gnu.org/software/repo-criteria-evaluation.html>
>
> According to the forge evaluation link it seems Gitlab is not 
> really an
> option and the front runner is Fedora's Pagure. Are the people 
> that did
> the evaluation participate in this list? Where do things stand 
> with
> Pagure?

I participate in the repo evaluation from time to time.  AIUI 
pagure.io has not been evaluated yet.

>
> *Daniel Fleischer*


-- 
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
           <https://ypei.me/assets/ypei-pubkey.txt>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  7:34           ` Tim Cross
  2021-08-27  8:25             ` tomas
@ 2021-08-28  1:39             ` Arthur Miller
  2021-08-28  2:38               ` Stefan Monnier
                                 ` (2 more replies)
  1 sibling, 3 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  1:39 UTC (permalink / raw)
  To: Tim Cross; +Cc: Daniel Fleischer, emacs-devel

Tim Cross <theophilusx@gmail.com> writes:

> Daniel Fleischer <danflscr@gmail.com> writes:
>
>> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>>
>>> I'm not sure this is true. I think virtually all developers are forced
>>> to suffer email, but a gorwing number don't use it. Often, all the
>>> discussions, notifications, comments etc are actually consumed via a
>>> mobile 'app'. For these users, logging into their inbox is frustrating
>>> and inconvenient because their inbox is full of pointless and old
>>> messages/notifications/alerts they have already seen/received via other
>>> channels. For these users, the primary reason they have an email address
>>> is to have something to put into the 'login' box for web services they
>>> use. Telling these users to use email to submit a patch is very similar
>>> to me being told when I started using email that I had to send in a hard
>>> copy via snail mail.
>>
>> It's a very intersting point about what email represent to different
>> people that arising from this discussion. I'm half your age and use
>> email for 2 reasons:
>>
>> 1. It's an identify for today's web. As such, it's becoming the main
>>    tool for tracking (especially as cookies phase out), so I use
>>    multiple boxes and regard them is disposable and spam-infected.
>>
>> 2. Receiving official documents from institutions.
>>
>> I don't talk to family, friends or coworkers via mail. Personally, I
>> think it's old, not secure or private by default, very inconsistent
>> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
>> imagine using it as a software engineering tool.
>>
>
> Yep, that mirrors what I'm seeing as well. Many younger users really use
> it primarily to provide a unique identifier (login) and for when they
> have to deal with institutions that don't provide other alternatives.
>
> The other interesting trend I'm seeing is with many companies now
> working to minimise email as part of their internal/external workflows.
> Many companies are finding it a huge resource sink, cause of unnecessary
> stress/pressure on staff, source of significant security concerns and a
> real problem for records management.
>
> From the Emacs project perspective, providing alternative web based
> workflows similar to what github/gitlab/sourceHut provide would be
> beneficial. The challenge seems to be in finding software which meets
> FSF requirements. In particular, a solution which is mature enough and
> is not based on non-free Javascript libraries. 

I wouldn't agree with you that young people don't know how to use email. That is
something you are deriving yourself. Sure Instagram, Facebook, Dicord, Twitter,
Slack etc might be very popular as a mean of communication, but saying that
young people don't know how to use email is stretching it too far.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  6:09             ` Eli Zaretskii
@ 2021-08-28  1:51               ` Arthur Miller
  2021-08-28  6:45                 ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  1:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, emacs-devel, danflscr, larsi, dgutov

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 26 Aug 2021 22:51:41 +0200
>> Cc: philipk@posteo.net, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com,
>>  larsi@gnus.org, emacs-devel@gnu.org
>> 
>> Maybe Emacs project should be better at informing users about Emacs bug tracker:
>> 
>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>> 
>> and this one:
>> 
>> https://debbugs.gnu.org/
>
> It's mentioned on line 45 of CONTRIBUTE, near the beginning of the
> "Getting involved with development" section.
>
>> and debbugs package for browsing bugs directly from Emacs?
>
> The debbugs package has several non-trivial dependencies, like email,
> and is probably not the first or the second thing newcomers should be
> messing with.

Maybe, but if somoeone is developer who would like to send in patch to Emacs
than they can probably setup email? Newcomer to Emacs dev, does not mean
newcomer to computing.

What about automating it for them?

Is this too wild: when someone signs FSF copyrights assignement, create
automatic "development mail account", which will work only to send and recieve
emails between certain addresses, the person and those used for Emacs
devs? We could then write a small pacakge to auto-setup persons account in
his/her Emacs that would work for bug repporting, debbugs, sending patches etc.

Limitiation because I guess FSF/GNU does not have resources to host free email
accounts for everyone.

We could then abstract parts of PR based worklfow on top of email.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Structured debbugs list per project
  2021-08-27  7:38             ` tomas
@ 2021-08-28  1:52               ` Arthur Miller
  2021-08-28 15:43               ` Michael Albinus
  1 sibling, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  1:52 UTC (permalink / raw)
  To: tomas; +Cc: Michael Albinus, emacs-devel

tomas@tuxteam.de writes:

> On Fri, Aug 27, 2021 at 09:36:52AM +0200, Michael Albinus wrote:
>> <tomas@tuxteam.de> writes:
>> 
>> > There's no reason to not have a web accessible bug mail archive
>> > indexed by bug number, for the webby folks our there. Perhaps
>> > debbugs could implement that... oh wait [1]!
>> >
>> > SCNR
>> >
>> > [1] https://debbugs.gnu.org/db/pa/lemacs.html
>> 
>> Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
>> hard.
>
> Michael, you rock :)
>
> Cheers
>  - t
+1

Yes you do rock Michael!



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  8:25             ` tomas
                                 ` (2 preceding siblings ...)
  2021-08-27 16:59               ` [External] : " Drew Adams
@ 2021-08-28  2:01               ` Arthur Miller
  3 siblings, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  2:01 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

<tomas@tuxteam.de> writes:

> On Fri, Aug 27, 2021 at 05:34:26PM +1000, Tim Cross wrote:
>
> [...]
>
>> Yep, that mirrors what I'm seeing as well. Many younger users really use
>> it primarily to provide a unique identifier (login) and for when they
>> have to deal with institutions that don't provide other alternatives.
>
> I think part of the rush is nudge pressure applied by the Big Ones.
> It's not possible to monetise mail in the same way as it is possible
> to do with whatsapp, tiktok, twitter and the uncountable more or less
> "secure" messengers popping up here and there.
>
> The nice thing about those communications platforms (nice from the
> perspective of the venture capitalist) is that there's no separation
> of platform and UI, so they get direct control of the user's perception.
Another aspect of those is one we touched on in some of our previous
conversations a year or so ago.

The personal or company PR (public relations). It is sort of CV, persons or a
companies track of popularity, what useful and how much they have done and so
on. It is all about selection :). That is why Instagram is so popular I guess.

Email based workflow does not promote same degree of self-promotion for people,
so they will prefer public stuff. When they give you a PR it is visible on their
GH/GL, when they send you a patch, there is a record in some mail database, but
it is not as visible. 

> I opt out of that. Count me in whenever there is a platform which
> separates transport and clients the way mail does and has at least
> some choice of client applications with a perspective of diversity.
>
>> The other interesting trend I'm seeing is with many companies now
>> working to minimise email as part of their internal/external workflows.
>> Many companies are finding it a huge resource sink, cause of unnecessary
>> stress/pressure on staff, source of significant security concerns and a
>> real problem for records management.
>
> I have watched this process around the 2010s in one company. The
> decision was made at top level (they were convinced by some Microsoft 
> salesperson [1] to switch to Office 365 instead of mail, because...
> mail is old). Today, they still use mail, but have outsourced their
> whole communications infrastructure to Microsoft, GDPR be dammed.
Yes, everybody still uses mail, and a normal day in office for many, many peopel
is to just sit with Outlook or Lotus Notes and answer/write mails 8 hours a
day. I have seen this for last 15 years, but I do see a shift toward instant
messaging and video messaging/ip calls, amongst younger generation. I mean
"younger" in this context is in later 40's now :). But email is still the prime
way of "recording" stuff, confirming so to say.

> The resource sink, stress and pressure stemmed rather from that
> change, for those who had to use that "new" platform (not to
> talk about staff layoffs for the old sysadmins, but I disgress).
>
> Those having taken the decisions didn't have to use O365, they
> have secretaries. For them, it was success.
>
> This may sound like an off-topic rant, but I'm serious. Not all
> of this "mail is old" meme is for real. Some of it is propaganda
> (I emphasise: /some/ of it). So we should take each critique
> and address it one by one.
>
> To put it in other words: I won't pay a wholesale-ish "mail is
> old" argument. I want to have more solid stuff.
>
> Cheers
>
> [1] https://en.wikipedia.org/wiki/Gr%C3%ADma
>
>  - t
Your rants are always spot on. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 12:03                 ` tomas
@ 2021-08-28  2:04                   ` Arthur Miller
  0 siblings, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  2:04 UTC (permalink / raw)
  To: tomas; +Cc: Eli Zaretskii, emacs-devel

tomas@tuxteam.de writes:

> On Fri, Aug 27, 2021 at 02:49:02PM +0300, Eli Zaretskii wrote:
>
> [...]
>
>> > I have watched this process around the 2010s in one company [...]
>
>> Office 365 includes Outlook,
>
> I know. I lived it :)
>
>>                             so I don't think you interpret that move
>> correctly.  It is most probably meant to avoid maintaining email
>> infrastructure in the company itself.
>
> This was but part of the equation (I had the chance to talk to some
> folks next to the decision makers). Actually, this part of the equation
> was the more problematic one, because of GDPR. Salespeople promised
> this wouldn't be a problem, because "all servers would be in the EU".
> Aha :-)
>
> The other was "mail is old, and here we have something *much* better".
Yes they are pushing hard on Teams. My company is using it extensively for
meetings, calendar, communication and even some logging. They require some
people to write daily repports in Teams so that manager can go in and read it.

> This was also the narrative the whole "change management" machinery
> was built around, with "planes", "pilots" and "seats" and whatnot.
>
> (Will stop now, because seriously off-topic)
>
> Cheers
>  - t



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 18:19       ` João Távora
@ 2021-08-28  2:07         ` Arthur Miller
  2021-08-28  2:15           ` Lars Ingebrigtsen
  2021-08-29  3:01         ` Richard Stallman
  1 sibling, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  2:07 UTC (permalink / raw)
  To: João Távora
  Cc: Eli Zaretskii, Daniel Fleischer, Philip K., emacs-devel

João Távora <joaotavora@gmail.com> writes:

> On Fri, Aug 27, 2021, 12:31 Eli Zaretskii <eliz@gnu.org> wrote:
>
>  Agreed.  We don't need to force everyone to use a single workflow.  We
>  should have a platform that supports reasonably well the different
>  popular workflows.
>
> I wish this point was stressed more often. Git, to which we've switched reasonably recently after some pain, accommodates many
> many workflows. We should embrace that!!
>
> E.g. if browser living people want to make PRs to an intermediate repo on GitHub, they can today! And then once they're
> reasonably stable and agreed upon, some email wizard (really, can be me, even though I'm not really a wizard) can push them to
> main repo, and even adjust a commit message or two. Git provides lots of commands for that,. I'm happy to explain and document
> them, though I doubt I'm the only such expert here.
>
> The main question is where the discussion happens: it has to be email, period. And right now it's debbugs and emacs-devel. And
> yes I know that GitHub/gitlab do pretty links automatically between web UI parts, but how is that so different from sending email
> where you say you have a public branch with x commits here or there?
>
> My two cents,
> João

There is also an interesting parallel: why doesn't peopel complain to Linus to
move Kernel development to more modern workflow? 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:07         ` Arthur Miller
@ 2021-08-28  2:15           ` Lars Ingebrigtsen
  2021-08-29  3:00             ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28  2:15 UTC (permalink / raw)
  To: Arthur Miller
  Cc: Philip K.,
	Eli Zaretskii, Daniel Fleischer, João Távora,
	emacs-devel

Arthur Miller <arthur.miller@live.com> writes:

> There is also an interesting parallel: why doesn't peopel complain to Linus to
> move Kernel development to more modern workflow? 

They do.

This is getting off-topic.  Emacs will change to a new system when we
can find a system that's good enough, and offers both an email work flow
(for those that prefer that) as well as a non-email work flow (for those
that prefer that).

We haven't found such a system yet.  sr.ht is perhaps an option, but my
first impression is that it's too different from GitHub/Lab, really.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:07   ` Stefan Monnier
@ 2021-08-28  2:31     ` Arthur Miller
  2021-08-28 12:23       ` Stefan Monnier
  2021-08-28  5:57     ` Eli Zaretskii
  2021-08-30 15:26     ` debbugs [was Re: Gitlab Migration] Glenn Morris
  2 siblings, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  2:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel, Daniel Fleischer, Daniel Martín

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Perhaps the people that contribute regularly to Emacs could describe
>> their workflow in more detail.  For example, things like how they like
>> to interact with bug reports (if they use the Debbugs Emacs package, for
>> example),
>
> FWIW, here are my main criticisms of debbugs for my own personal use:
>
> - Can't search the database when I'm offline.
>   I really wish the database was stored in Git, so I could easily have
>   a clone of it.  This said, compared to other issue tracking systems,
>   the fact that it works over email makes it at least partly usable
>   offline, which is a big plus.

I think storing it in Git itself would be very nice indeed.

I wonder if it would even be possible to tuck git bases workflow on top of it?

Every bug could be a branch, with each email as a commit to that
branch. If we could git clone it locally, people could push/pull bug repports
instead of sending mails if they prefer? 

> - No notion of "subscription" to a bug, so replies will sometimes fail
>   to reach me.
>
> - The notion of "archived" bugs is a pain in the rear when you send
>   a new message and the message just bounces back with "the bug is
>   archived".
>   Either get rid of it, or automatically unarchive bugs when a new reply
>   is received, or something (e.g. ask for a confirmation message to
>   unarchive the bug and add the already sent message), but the current
>   way this is handled is *really* poor.
>
> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>   I'd like, and maybe some of it can be done via tags and other things
>   already, but I think I'd like it if bugs could be "assigned" to persons
>   and/or to files and/or to "subsystems", and maybe even combine this
>   with ways to describe relationships between those things (so the
>   search tools can known that a given file belongs to a particular
>   subsystem, for example).
>
> The poor web UI is of course another criticism but it mostly doesn't
> affect me.
>
>
>         Stefan



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  1:39             ` Arthur Miller
@ 2021-08-28  2:38               ` Stefan Monnier
  2021-08-28  2:59                 ` Arthur Miller
  2021-08-28  6:57                 ` tomas
  2021-08-28  3:21               ` Gitlab Migration Tim Cross
  2021-08-28  6:26               ` Eli Zaretskii
  2 siblings, 2 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-28  2:38 UTC (permalink / raw)
  To: Arthur Miller; +Cc: Tim Cross, Daniel Fleischer, emacs-devel

> I wouldn't agree with you that young people don't know how to use
> email.  That is something you are deriving yourself.  Sure Instagram,
> Facebook, Dicord, Twitter, Slack etc might be very popular as a mean
> of communication, but saying that young people don't know how to use
> email is stretching it too far.

I think the issue is not use of email as such, but use of mailing-lists.
In my experience the reluctance to use email is that they feel
uncomfortable sending email to a potentially large number of persons.
In contrast posting on a forum doesn't impose anything on anyone (in
their mind) because those who read it have to actively go and look
for it.
[ Of course, it doesn't make much sense, really, but this is about
  people's perceptions, not about anything rational.  ]


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:38               ` Stefan Monnier
@ 2021-08-28  2:59                 ` Arthur Miller
  2021-08-28  6:57                 ` tomas
  1 sibling, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  2:59 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Tim Cross, Daniel Fleischer, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I wouldn't agree with you that young people don't know how to use
>> email.  That is something you are deriving yourself.  Sure Instagram,
>> Facebook, Dicord, Twitter, Slack etc might be very popular as a mean
>> of communication, but saying that young people don't know how to use
>> email is stretching it too far.
>
> I think the issue is not use of email as such, but use of mailing-lists.
> In my experience the reluctance to use email is that they feel
> uncomfortable sending email to a potentially large number of persons.
> In contrast posting on a forum doesn't impose anything on anyone (in
> their mind) because those who read it have to actively go and look
> for it.
> [ Of course, it doesn't make much sense, really, but this is about
>   people's perceptions, not about anything rational.  ]
>
>
>         Stefan

Mailing lists are different though indeed. Anyone still using News servers?

I don't know, I agree that people are not used mail archives, I don't use them
myself much either. Should we tack a forum interface on mailing archives? Like
SX? I don't think people use forums much either. Google has removed their option
"search in webforums" they used to have some 10+ years ago (I don't remember
what was the real name).

Someone (I think Dmitry) mentioned that it is easier to look in "issues" list on
GH, I don't think it is different at emacs mail archive interface on the web
at all. It is just that "issues" are integrated in the GH interface. Emacs mail
archive is not integrated anywhere but is a solo web page, which lots of peeps
probably don't know about.

But your mention of debbugs in Git, is not bad in that regard. I don't know how
is developing Savannah web service, but I suppose that mail archives and git
intefaces are on same computers, at least, payed by same account. Maybe FSF/GNU
could consider rewamping the interface to projects and make them more
gitlab/github alike.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 16:20 Gitlab Migration Daniel Fleischer
                   ` (5 preceding siblings ...)
  2021-08-27 13:35 ` Daniel Martín
@ 2021-08-28  2:59 ` Richard Stallman
  2021-08-28  4:51   ` Arthur Miller
  2021-08-28  7:03   ` Eli Zaretskii
  6 siblings, 2 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-28  2:59 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: emacs-devel

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

We used to recommend GitLab as better than GitHub (though only
barely acceptable).  However, GitLab has got worse, and we
should stop recommending it at all.

notabug.org and sr.ht are considerably better, by our ethical
evaluation standards.

If it is a matter of running our own copy of one of these,
we have an issue with any Javascript code.  If it is in fact free,
but doesn't properly state its license and source code, we would
need to fix that.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 17:24 ` Philip Kaludercic
                     ` (6 preceding siblings ...)
  2021-08-27 18:02   ` Augusto Stoffel
@ 2021-08-28  2:59   ` Richard Stallman
  2021-08-28  6:58     ` Eli Zaretskii
  7 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-28  2:59 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: danflscr, emacs-devel

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

  > Shouldn't it be easier to send an email than create an account, navigate
  > some web UI and fill in some form?

Yes it is.  However, it's more than just ease of use at stake.
You also need to have an internet connection at the moment that you
try to use the web forum.  Not so for sending email.

But those are merely practical considerations.  There are also
moral considerations.

To make an account on a web forum, you have to use that platform in
the way it is set up to require.  You have to accept its terms and
conditions, which may be morally unacceptable.

When you send email, you use your own choice of tools and platforms --
the same ones you used to send mail to a different forum the day
before.

This is why the GNU Project continues to specify that a GNU package
should have a published bug-reporting email address.

    > A mailing list does not allow this, so for newcomers the fear of
    > "doing something wrong" is high.  

It is ok to offer a web forum as an alternative interface for sending
a bug report, just as Emacs has M-x report-emacs-bug.  As long as the
forum's software and use conditions are ethical.

Another way to encourage users to report bugs is to focus on our
appreciation for bug reports, and show it whenever users give us a bug
report.  It's a GNU Project policy to state thanks for each bug
report.

                                        Many projects have an issue
    > reporting template now, and that can be nice.

That sounds good.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 23:52   ` Tim Cross
@ 2021-08-28  2:59     ` Richard Stallman
  2021-08-28  4:50       ` Arthur Miller
  0 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-28  2:59 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

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

  > They communicate/share information via slack, discord, reddit, instagram
  > etc.

Those are online dis-services -- they treat users unjustly.
Each of them requires users to run nonfree software to talk to it,
even when the user is doing so through a web browser.
Several of them have other unjust practices I know of;
see stallman.org/slack.html, discord.html, instagram.html.

To recommend that people use one of them would contradict our goal of
computing that respects the user's freedom.  Thus, we can't recommend
any of them.  Whatever practical "advantages" it might have, they
could not make up for the moral contradiction it would cause.

From the node References in the GNU Coding Standards:

======================================================================
A web page recommends a program in an implicit but particularly strong
way if it requires users to run that program in order to use the page.
Many pages contain Javascript code which they recommend in this way.
This Javascript code may be free or non-free, but non-free is the usual
case.

If the purpose for which you would refer to the page cannot be carried
out without running non-free Javascript code, then you should not refer
to it.  Thus, if the purpose of referring to the page is for people to
view a video, or subscribing to a mailing list, and the viewing or
subscribing fail to work if the user's browser blocks the non-free
Javascript code, then don't refer to that page.
======================================================================

It's fine if users have the _option_ of communicating with the
maintainers and developers via some interface other than email.  (Or
ten different interfaces other than email.)  But when some of them use
it. that must not compel the maintainers and developers to use it too.


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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 18:51 ` Stefan Monnier
  2021-08-26 19:13   ` john muhl
@ 2021-08-28  3:03   ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-28  3:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: danflscr, emacs-devel

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

  > You forgot another one: we want the code to be hosted on machines under
  > the control of the GNU project.

Yes, indeed.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  1:39             ` Arthur Miller
  2021-08-28  2:38               ` Stefan Monnier
@ 2021-08-28  3:21               ` Tim Cross
  2021-08-28  5:02                 ` Arthur Miller
  2021-08-28  6:26               ` Eli Zaretskii
  2 siblings, 1 reply; 525+ messages in thread
From: Tim Cross @ 2021-08-28  3:21 UTC (permalink / raw)
  To: Arthur Miller; +Cc: Daniel Fleischer, emacs-devel


Arthur Miller <arthur.miller@live.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Daniel Fleischer <danflscr@gmail.com> writes:
>>
>>> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>>>
>>>> I'm not sure this is true. I think virtually all developers are forced
>>>> to suffer email, but a gorwing number don't use it. Often, all the
>>>> discussions, notifications, comments etc are actually consumed via a
>>>> mobile 'app'. For these users, logging into their inbox is frustrating
>>>> and inconvenient because their inbox is full of pointless and old
>>>> messages/notifications/alerts they have already seen/received via other
>>>> channels. For these users, the primary reason they have an email address
>>>> is to have something to put into the 'login' box for web services they
>>>> use. Telling these users to use email to submit a patch is very similar
>>>> to me being told when I started using email that I had to send in a hard
>>>> copy via snail mail.
>>>
>>> It's a very intersting point about what email represent to different
>>> people that arising from this discussion. I'm half your age and use
>>> email for 2 reasons:
>>>
>>> 1. It's an identify for today's web. As such, it's becoming the main
>>>    tool for tracking (especially as cookies phase out), so I use
>>>    multiple boxes and regard them is disposable and spam-infected.
>>>
>>> 2. Receiving official documents from institutions.
>>>
>>> I don't talk to family, friends or coworkers via mail. Personally, I
>>> think it's old, not secure or private by default, very inconsistent
>>> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
>>> imagine using it as a software engineering tool.
>>>
>>
>> Yep, that mirrors what I'm seeing as well. Many younger users really use
>> it primarily to provide a unique identifier (login) and for when they
>> have to deal with institutions that don't provide other alternatives.
>>
>> The other interesting trend I'm seeing is with many companies now
>> working to minimise email as part of their internal/external workflows.
>> Many companies are finding it a huge resource sink, cause of unnecessary
>> stress/pressure on staff, source of significant security concerns and a
>> real problem for records management.
>>
>> From the Emacs project perspective, providing alternative web based
>> workflows similar to what github/gitlab/sourceHut provide would be
>> beneficial. The challenge seems to be in finding software which meets
>> FSF requirements. In particular, a solution which is mature enough and
>> is not based on non-free Javascript libraries. 
>
> I wouldn't agree with you that young people don't know how to use email. That is
> something you are deriving yourself. Sure Instagram, Facebook, Dicord, Twitter,
> Slack etc might be very popular as a mean of communication, but saying that
> young people don't know how to use email is stretching it too far.

I never said they don't know how to use email - I said they were not
interested in using email. They use it when they are forced to, but it
is not their preferred choice. We even asked students what they wanted
and when you broke that information down by age, nearly 80% of under 25s
indicated they would prefer non-email based communications. This is only
one data point from one institution and only for one year, so there
could be sampling error, cultural variation and possibly question bias
based on wording etc. However, the results were in line with other
feedback and comments. The preference for email also increased with age
- older students showed a higher preference for email, which means the
results could be related to experience and user maturity - we won't know
until more time has passed.

I cannot provide specific details because the information is classified
as sensitive and internal only. It was part of analysis done at a
smaller University (approx 25k students) where the main objective was to
determine if providing students with an email account (actually o365
account), was beneficial or not. The result was that the majority of
students were not interested in the email account (either because they
already had one or because email was not a comms channel they cared
about), but they did want the o365 account because of the access it gave
them to other things, most notably Office suite. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:59     ` Richard Stallman
@ 2021-08-28  4:50       ` Arthur Miller
  2021-08-29  3:03         ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  4:50 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Tim Cross, emacs-devel

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > They communicate/share information via slack, discord, reddit, instagram
>   > etc.
>
> Those are online dis-services -- they treat users unjustly.
> Each of them requires users to run nonfree software to talk to it,
> even when the user is doing so through a web browser.
> Several of them have other unjust practices I know of;
> see stallman.org/slack.html, discord.html, instagram.html.
>
> To recommend that people use one of them would contradict our goal of
> computing that respects the user's freedom.  Thus, we can't recommend
> any of them.  Whatever practical "advantages" it might have, they
> could not make up for the moral contradiction it would cause.

? I didn't recommend to anyone to use those, nor did I spoke in their favor, I
just generally spoke about what some people prefer and I try to speculate why.

But yes, they are all there to exploit users in the very end, because users are
their product.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:59 ` Gitlab Migration Richard Stallman
@ 2021-08-28  4:51   ` Arthur Miller
  2021-08-28  7:03   ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  4:51 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Daniel Fleischer, emacs-devel

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> We used to recommend GitLab as better than GitHub (though only
> barely acceptable).  However, GitLab has got worse, and we
> should stop recommending it at all.
>
> notabug.org and sr.ht are considerably better, by our ethical
> evaluation standards.
>
> If it is a matter of running our own copy of one of these,
> we have an issue with any Javascript code.  If it is in fact free,
> but doesn't properly state its license and source code, we would
> need to fix that.

So unify savannah with debbugs and mail archives in some way that resembles what
people consider is "modern workflow"?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 22:50         ` Yuchen Pei
@ 2021-08-28  4:57           ` Werner LEMBERG
  2021-08-28  7:44             ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Werner LEMBERG @ 2021-08-28  4:57 UTC (permalink / raw)
  To: emacs-devel


>> The two "external" items (reCAPTCHA and LibreJS) might be hard
>> requirements from RMS, though.
> 
> Well, they are problematic because reCAPTCHA is nonfree, and the
> mandatory javascript programs have no license information that comes
> with them (hence not librejs-compliant).  [...]

Just curious: What about using a gitlab instance (which uses the
GPL-compatible Expat License) on either gnu.org or an existing one
like gitlab.freedesktop.org?  Has this already been considered?  I
couldn't find this in the emacs-devel list archive.


    Werner



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  3:21               ` Gitlab Migration Tim Cross
@ 2021-08-28  5:02                 ` Arthur Miller
  2021-08-28  7:53                   ` Tim Cross
  0 siblings, 1 reply; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  5:02 UTC (permalink / raw)
  To: Tim Cross; +Cc: Daniel Fleischer, emacs-devel

Tim Cross <theophilusx@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> Daniel Fleischer <danflscr@gmail.com> writes:
>>>
>>>> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>>>>
>>>>> I'm not sure this is true. I think virtually all developers are forced
>>>>> to suffer email, but a gorwing number don't use it. Often, all the
>>>>> discussions, notifications, comments etc are actually consumed via a
>>>>> mobile 'app'. For these users, logging into their inbox is frustrating
>>>>> and inconvenient because their inbox is full of pointless and old
>>>>> messages/notifications/alerts they have already seen/received via other
>>>>> channels. For these users, the primary reason they have an email address
>>>>> is to have something to put into the 'login' box for web services they
>>>>> use. Telling these users to use email to submit a patch is very similar
>>>>> to me being told when I started using email that I had to send in a hard
>>>>> copy via snail mail.
>>>>
>>>> It's a very intersting point about what email represent to different
>>>> people that arising from this discussion. I'm half your age and use
>>>> email for 2 reasons:
>>>>
>>>> 1. It's an identify for today's web. As such, it's becoming the main
>>>>    tool for tracking (especially as cookies phase out), so I use
>>>>    multiple boxes and regard them is disposable and spam-infected.
>>>>
>>>> 2. Receiving official documents from institutions.
>>>>
>>>> I don't talk to family, friends or coworkers via mail. Personally, I
>>>> think it's old, not secure or private by default, very inconsistent
>>>> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
>>>> imagine using it as a software engineering tool.
>>>>
>>>
>>> Yep, that mirrors what I'm seeing as well. Many younger users really use
>>> it primarily to provide a unique identifier (login) and for when they
>>> have to deal with institutions that don't provide other alternatives.
>>>
>>> The other interesting trend I'm seeing is with many companies now
>>> working to minimise email as part of their internal/external workflows.
>>> Many companies are finding it a huge resource sink, cause of unnecessary
>>> stress/pressure on staff, source of significant security concerns and a
>>> real problem for records management.
>>>
>>> From the Emacs project perspective, providing alternative web based
>>> workflows similar to what github/gitlab/sourceHut provide would be
>>> beneficial. The challenge seems to be in finding software which meets
>>> FSF requirements. In particular, a solution which is mature enough and
>>> is not based on non-free Javascript libraries. 
>>
>> I wouldn't agree with you that young people don't know how to use email. That is
>> something you are deriving yourself. Sure Instagram, Facebook, Dicord, Twitter,
>> Slack etc might be very popular as a mean of communication, but saying that
>> young people don't know how to use email is stretching it too far.
>
> I never said they don't know how to use email - I said they were not
> interested in using email. They use it when they are forced to, but it
Ok. Fair enough. It was maybe oversimplification there by me.

> is not their preferred choice. We even asked students what they wanted
> and when you broke that information down by age, nearly 80% of under 25s
> indicated they would prefer non-email based communications. This is only
> one data point from one institution and only for one year, so there
> could be sampling error, cultural variation and possibly question bias
> based on wording etc. However, the results were in line with other
> feedback and comments. The preference for email also increased with age
> - older students showed a higher preference for email, which means the
> results could be related to experience and user maturity - we won't know
> until more time has passed.
>
> I cannot provide specific details because the information is classified
> as sensitive and internal only. It was part of analysis done at a
> smaller University (approx 25k students) where the main objective was to
> determine if providing students with an email account (actually o365
> account), was beneficial or not. The result was that the majority of
> students were not interested in the email account (either because they
> already had one or because email was not a comms channel they cared
> about), but they did want the o365 account because of the access it gave
> them to other things, most notably Office suite.

I understand, but that can also be interpretted as if they prefer mail as
they getting more experienced. I also don't really understand what is problem
with emails. Smartphones have almost removed distinction between a so called an
instant message and and email. Email has become just yet another messaging
media.

What I have suggested in several comments by now, is that it is maybe possible
to tuck git workflow on existing mail workflow. Maybe some tasks could be
automated I don't know.

So will your university listen to the students and open a discord channel or
was it snappchat they prefer? Sorry, hope you don't mind a joke.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 11:33           ` Dmitry Gutov
@ 2021-08-28  5:05             ` Arthur Miller
  2021-08-29  1:27             ` Po Lu
  1 sibling, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  5:05 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Po Lu, Lars Ingebrigtsen, Daniel Fleischer, Philip Kaludercic,
	emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 27.08.2021 04:31, Arthur Miller wrote:
>>>> We also have a bunch of formal rules for submissions which tend to
>>>> seem intimidating. A CI with an automated checker running against all
>>>> PRs can alleviate that problem.
>>> I don't know enough git to tell you exactly what it is, but perhaps
>>> whatever runs each time I check-in something to my local copy of the
>>> repository that checks for indentation and extraneous whitespace could
>>> also work for this?
>> Couldn't identation and extraneous space be solved by either running after save
>> hook in Emacs, or by running emacs in batch mode as a git hook?
>
> Yes, you're both talking about git hooks. A minor disadvantage is that a hook
> needs to be installed, and then a bug in a hook implementation can stop you from
> being able to make a commit (there are overrides, but those require more
> googling).
Yes, hook is a one way to implement it, but that particular case is solved by
just after file save hook. But we could also develop an emacs package that does
some basics checks and stuff against local repo? Maybe Cask, edev, I don't know? 

I just answer on someone asking for these basics checks.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:07   ` Stefan Monnier
  2021-08-28  2:31     ` Arthur Miller
@ 2021-08-28  5:57     ` Eli Zaretskii
  2021-08-28  9:25       ` Alan Third
  2021-08-30 15:26     ` debbugs [was Re: Gitlab Migration] Glenn Morris
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  5:57 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel, danflscr, mardani29

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Daniel Fleischer <danflscr@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 17:07:10 -0400
> 
> - The notion of "archived" bugs is a pain in the rear when you send
>   a new message and the message just bounces back with "the bug is
>   archived".

That is true, but I don't think we ever looked at the alternatives in
this respect.  I consider it a minor (though quite annoying)
misfeature, certainly not something serious enough to change the
platform.  If SourceHut or whatever we decide to use doesn't have this
misfeature, it's bonus points, of course.

> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>   I'd like, and maybe some of it can be done via tags and other things
>   already, but I think I'd like it if bugs could be "assigned" to persons
>   and/or to files and/or to "subsystems", and maybe even combine this
>   with ways to describe relationships between those things (so the
>   search tools can known that a given file belongs to a particular
>   subsystem, for example).

We should first come up with a meaningful classification that would
help in handling the bugs.  Only then we can talk about the
implementation.  I don't have any practical suggestion for
classification ATM, and frankly, as long as we have only a handful of
people doing this, it doesn't sound very important.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:09         ` Gitlab Migration Dmitry Gutov
  2021-08-27 21:17           ` Theodor Thornhill
@ 2021-08-28  6:00           ` Eli Zaretskii
  2021-08-29  2:27             ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  6:00 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, monnier, emacs-devel

> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Aug 2021 00:09:41 +0300
> 
>  From what I have seen of it, it's email-first, and far from "full and 
> convenient support for ... web".
> 
> For example, those quality-of-life features that Gitlab has in the 
> browser which I previously figured would be difficult to translate  to 
> email (the code review workflow, with inline comments and updates from 
> the branch; automatically updated CI indicators and links to builds; 
> editing of messages) are predictably absent.

That sounds worrisome.

Can you tell how did you see what SourceHut offers in this department,
so others (myself included) could have a look?  I cannot find any
documentation of the features.

> Of course, it should still be a significant step forward compared to the 
> current situation.

Can you elaborate why you think so, given the lack of the above
features?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:17           ` Theodor Thornhill
  2021-08-27 21:35             ` Dmitry Gutov
@ 2021-08-28  6:01             ` Eli Zaretskii
  2021-08-28  6:26               ` Theodor Thornhill
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  6:01 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, emacs-devel, danflscr, monnier, dgutov

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: philipk@posteo.net, Daniel Fleischer <danflscr@gmail.com>,
>  emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 23:17:32 +0200
> 
> > For example, those quality-of-life features that Gitlab has in the 
> > browser which I previously figured would be difficult to translate  to 
> > email (the code review workflow, with inline comments and updates from 
> > the branch; automatically updated CI indicators and links to builds; 
> > editing of messages) are predictably absent.
> 
> This isn't really true though.  There definitely are links to builds and
> inline comments.  Though I agree on parts of this.  One missing thing as
> I see it is the updated patch. You need to find the latest patches, and
> it won't update as in GitHub when you add another "oops" commit.

Can you point to a place where one could see this stuff in action, or
described with screenshots, and make up one's mind regarding what's
there and what isn't?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:01             ` Eli Zaretskii
@ 2021-08-28  6:26               ` Theodor Thornhill
  2021-08-28  7:30                 ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28  6:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dgutov, monnier, philipk, danflscr, emacs-devel



On 28 August 2021 08:01:42 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: philipk@posteo.net, Daniel Fleischer <danflscr@gmail.com>,
>>  emacs-devel@gnu.org
>> Date: Fri, 27 Aug 2021 23:17:32 +0200
>> 
>> > For example, those quality-of-life features that Gitlab has in the 
>> > browser which I previously figured would be difficult to translate  to 
>> > email (the code review workflow, with inline comments and updates from 
>> > the branch; automatically updated CI indicators and links to builds; 
>> > editing of messages) are predictably absent.
>> 
>> This isn't really true though.  There definitely are links to builds and
>> inline comments.  Though I agree on parts of this.  One missing thing as
>> I see it is the updated patch. You need to find the latest patches, and
>> it won't update as in GitHub when you add another "oops" commit.
>
>Can you point to a place where one could see this stuff in action, or
>described with screenshots, and make up one's mind regarding what's
>there and what isn't?

Sure!

https://lists.sr.ht/~technomancy/fennel/patches/24386

It shows inline comments and link to a succeeding autotriggered build. As for all conveniences in is hard to tell, since that list is a little subjective. 

I think we'd need a definitive list of conveniences we need as a minimum, so that we can actually see what's missing. SourceHut now offers the same or equivalent workflow to GitHub, yet often it is differs in spirit. Many things are available through the web, but some are likely not, considering the different products age and funding

Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  1:39             ` Arthur Miller
  2021-08-28  2:38               ` Stefan Monnier
  2021-08-28  3:21               ` Gitlab Migration Tim Cross
@ 2021-08-28  6:26               ` Eli Zaretskii
  2 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  6:26 UTC (permalink / raw)
  To: Arthur Miller; +Cc: theophilusx, danflscr, emacs-devel

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sat, 28 Aug 2021 03:39:56 +0200
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> I wouldn't agree with you that young people don't know how to use email.

s/don't know/don't like/



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  1:51               ` Arthur Miller
@ 2021-08-28  6:45                 ` Eli Zaretskii
  2021-08-28  8:53                   ` Arthur Miller
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  6:45 UTC (permalink / raw)
  To: Arthur Miller; +Cc: philipk, emacs-devel, danflscr, larsi, dgutov

> From: Arthur Miller <arthur.miller@live.com>
> Cc: dgutov@yandex.ru,  philipk@posteo.net,  danflscr@gmail.com,
>   larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 03:51:40 +0200
> 
> >> and debbugs package for browsing bugs directly from Emacs?
> >
> > The debbugs package has several non-trivial dependencies, like email,
> > and is probably not the first or the second thing newcomers should be
> > messing with.
> 
> Maybe, but if somoeone is developer who would like to send in patch to Emacs
> than they can probably setup email? Newcomer to Emacs dev, does not mean
> newcomer to computing.

The main purpose of the Emacs debbugs package is not to send patches.
Sending patches when you have email set up is trivial and doesn't need
the debbugs package.

> What about automating it for them?
> 
> Is this too wild: when someone signs FSF copyrights assignement, create
> automatic "development mail account", which will work only to send and recieve
> emails between certain addresses, the person and those used for Emacs
> devs? We could then write a small pacakge to auto-setup persons account in
> his/her Emacs that would work for bug repporting, debbugs, sending patches etc.
> 
> Limitiation because I guess FSF/GNU does not have resources to host free email
> accounts for everyone.

You mean, set up email account on GNU servers?  That's problematic in
more than one sense, some of which you mention above.

And what would be the advantages?

> We could then abstract parts of PR based worklfow on top of email.

For people who are familiar with, and used to, the PR workflow using
Web forms, I don't think this would be an advantage.  The main purpose
of moving to a service we are discussing is to provide a familiar UI
to those contributors, with a special emphasis on occasional
contributors who don't have time, or don't want, to learn a new UI
just to contribute to Emacs.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:38               ` Stefan Monnier
  2021-08-28  2:59                 ` Arthur Miller
@ 2021-08-28  6:57                 ` tomas
  2021-08-28  7:41                   ` Eli Zaretskii
  2021-08-29  3:03                   ` Richard Stallman
  1 sibling, 2 replies; 525+ messages in thread
From: tomas @ 2021-08-28  6:57 UTC (permalink / raw)
  To: emacs-devel

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

On Fri, Aug 27, 2021 at 10:38:18PM -0400, Stefan Monnier wrote:
> > I wouldn't agree with you that young people don't know how to use
> > email [...]

> I think the issue is not use of email as such, but use of mailing-lists.
> In my experience the reluctance to use email is that they feel
> uncomfortable sending email to a potentially large number of persons.

Sometimes it comes down to trivial technique things.

For better or worse, some MUAs [1] and corporate-influenced
workflows have trained a significant part of the population to
top-quote.

While this might work in the context of personal mail, it fails
miserably in mailing lists, yielding a longer thread practically
unreadable.

On top of that, some MUAs (again, the same) don't know what a
Message-ID is and thread based on Subject. Resulting in monster
threads with the incredibly informative Subject "Re:".

The result is: "mail is broken". No, it's not. It's some MUAs,
and then, the whole rest, which, like lemmings on the cliff,
try to clone that disfunctional behaviour.

But yes, mail is broken.

Cheers

[1] I'm looking at you, Microsoft

 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:59   ` Richard Stallman
@ 2021-08-28  6:58     ` Eli Zaretskii
  2021-08-29  3:03       ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  6:58 UTC (permalink / raw)
  To: rms; +Cc: philipk, danflscr, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 27 Aug 2021 22:59:21 -0400
> Cc: danflscr@gmail.com, emacs-devel@gnu.org
> 
> When you send email, you use your own choice of tools and platforms --
> the same ones you used to send mail to a different forum the day
> before.
> 
> This is why the GNU Project continues to specify that a GNU package
> should have a published bug-reporting email address.

Not to be a whistle-blower, but if that's a rule, then some GNU
packages deviate from it.  Just two examples:

  $ ld --help
  ...
  Report bugs to <https://www.sourceware.org/bugzilla/>

  $ gdb --help
  ...
  Report bugs to <https://www.gnu.org/software/gdb/bugs/>.

> It's a GNU Project policy to state thanks for each bug report.

We do that, at least most of the time.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:59 ` Gitlab Migration Richard Stallman
  2021-08-28  4:51   ` Arthur Miller
@ 2021-08-28  7:03   ` Eli Zaretskii
  2021-08-28  8:12     ` Yuchen Pei
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  7:03 UTC (permalink / raw)
  To: rms; +Cc: danflscr, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 27 Aug 2021 22:59:20 -0400
> Cc: emacs-devel@gnu.org
> 
> notabug.org and sr.ht are considerably better, by our ethical
> evaluation standards.

Would someone please evaluate notabug.org wrt our expectations, and
post a summary?  TIA.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut (was: Re: Gitlab Migration)
  2021-08-27 20:45               ` GitLab feature request compared with SourceHut (was: Re: Gitlab Migration) Sean Whitton
@ 2021-08-28  7:18                 ` Tassilo Horn
  2021-08-28 15:09                   ` GitLab feature request compared with SourceHut Lars Ingebrigtsen
  0 siblings, 1 reply; 525+ messages in thread
From: Tassilo Horn @ 2021-08-28  7:18 UTC (permalink / raw)
  To: Sean Whitton
  Cc: philipk, danflscr, Theodor Thornhill, sir, monnier, larsi,
	emacs-devel, Eli Zaretskii

> CLOSELY INTEGRATED BUGTRACKER
>
> Looks a bit manual atm, but a big step up from debbugs because there
> is both e-mail control and clickable buttons.
> ...
>
> BUG REPORTING
>
> Filing bugs and starting mailing list threads are both just a matter of
> sending e-mails, so report-emacs-bug could do it.

One thing I have to note here is that todo.sr.ht simply assumes that
formatting is some kind of email and markdown, i.e., it'll handle

    > bla bla

as quotation but non-4-space or ```...``` wrapped code snippets will be
treated as normal text (become wrapped).  That's ok if you know it but
suprising if you don't.

Also, todo.sr.ht doesn't support attachments AFAIK, i.e., reports
accompanied with attached patches or screenshots illustrating the issue
aren't displayed.  So that's a major bummer which would need to be
worked on for making it suitable for emacs.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:26               ` Theodor Thornhill
@ 2021-08-28  7:30                 ` Eli Zaretskii
  2021-08-28  7:56                   ` Theodor Thornhill
  2021-08-28 10:18                   ` Daniel Fleischer
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  7:30 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, emacs-devel, danflscr, monnier, dgutov

> Date: Sat, 28 Aug 2021 08:26:14 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>  danflscr@gmail.com, emacs-devel@gnu.org
> 
> I think we'd need a definitive list of conveniences we need as a minimum, so that we can actually see what's missing. SourceHut now offers the same or equivalent workflow to GitHub, yet often it is differs in spirit. Many things are available through the web, but some are likely not, considering the different products age and funding

The list of issues we filed with GitLab was mostly about email-based
workflow and other relevant features, because the Web-based workflow
was supported by GitLab already.  It sounds like we now need to
augment that list by the requirements from the Web-based workflow,
since SourceHut and other platforms might lack them.

Would someone like to come with a list of such requirements?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:57                 ` tomas
@ 2021-08-28  7:41                   ` Eli Zaretskii
  2021-08-28  7:53                     ` tomas
  2021-08-29  3:03                   ` Richard Stallman
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  7:41 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

> Date: Sat, 28 Aug 2021 08:57:08 +0200
> From: <tomas@tuxteam.de>
> 
> For better or worse, some MUAs [1] and corporate-influenced
> workflows have trained a significant part of the population to
> top-quote.

We encourage people not to top-post, but don't require them not to do
so.  Some of them do, as you can clearly see in the archives.

> While this might work in the context of personal mail, it fails
> miserably in mailing lists, yielding a longer thread practically
> unreadable.

We generally suck it up and survive.  When the fraction of these is
not too high, it is not a problem in practice.

> On top of that, some MUAs (again, the same) don't know what a
> Message-ID is and thread based on Subject. Resulting in monster
> threads with the incredibly informative Subject "Re:".

That's what Rmail does, and I have yet to see a significant problem
with it, let alone that it broke my workflows.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  4:57           ` Werner LEMBERG
@ 2021-08-28  7:44             ` Eli Zaretskii
  2021-08-28  7:57               ` tomas
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  7:44 UTC (permalink / raw)
  To: Werner LEMBERG; +Cc: emacs-devel

> Date: Sat, 28 Aug 2021 04:57:08 +0000 (UTC)
> From: Werner LEMBERG <wl@gnu.org>
> 
> 
> >> The two "external" items (reCAPTCHA and LibreJS) might be hard
> >> requirements from RMS, though.
> > 
> > Well, they are problematic because reCAPTCHA is nonfree, and the
> > mandatory javascript programs have no license information that comes
> > with them (hence not librejs-compliant).  [...]
> 
> Just curious: What about using a gitlab instance (which uses the
> GPL-compatible Expat License) on either gnu.org or an existing one
> like gitlab.freedesktop.org?  Has this already been considered?  I
> couldn't find this in the emacs-devel list archive.

You mean, forking it and developing our own version free of those
problems?  That depends on the resources GNU could use for that: if
there's a need for significant changes, we'd need to maintain that
fork forever.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  5:02                 ` Arthur Miller
@ 2021-08-28  7:53                   ` Tim Cross
  2021-08-28  8:52                     ` Eli Zaretskii
                                       ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-28  7:53 UTC (permalink / raw)
  To: Arthur Miller; +Cc: Daniel Fleischer, emacs-devel


Arthur Miller <arthur.miller@live.com> writes:

>
> I understand, but that can also be interpretted as if they prefer mail as
> they getting more experienced.

Yes, I already pointed that out and said we won't know until more time
has passed. 

> I also don't really understand what is problem
> with emails. Smartphones have almost removed distinction between a so called an
> instant message and and email. Email has become just yet another messaging
> media.
>

Some of it is about ensuring all necessary information is included. In
many 'business' processes, email is a problem because people neglect to
include crucial information in the message. If on the other hand, they
are required to fill in a form, then mandatory or important information
can be gathered and the content will be in a set format, enabling easier
automation of processing.

Despite what others have claimed, the security problems with email have
NOT been addressed. It is still one of the major vectors for
compromising access via social engineering, major vector for infection
from ransomeware, frequent source of privacy breeches and a common means
used to get sensitive data out of an organisation. Even having encrypted
messages is overly complex for most users and a nightmare to administer
for large organisations. Some of these issues can be partially mitigated
through training/education and various technologies, but these tend to
significantly increase the cost and administration overheads and often
make the service less convenient for users. There is also an element of
it all being 'too hard' (from an administration perspective). 

For younger people, I suspect part of it is just a perception of email
as being old and outdated and not fitting as well with their 'style' of
communication, which tends to be about short messages and group chat in
near 'real time'.

> What I have suggested in several comments by now, is that it is maybe possible
> to tuck git workflow on existing mail workflow. Maybe some tasks could be
> automated I don't know.
>

I'm sure we could use git facilities to enhance the existing workflows,
but that isn't what people are asking for. Those using the existing
email based workflows are not the ones suggesting adoption of more
github/gitlab type functionality. I get the impression that those who
use the existing workflows are quite happy with the current situation.
this is what makes the suggestion of sourceHut as a solution uncertain
as it isn't clear it would provide the web UI facilities being asked for
and may only add a little sugar to the existing workflows, which may
make the effort and change management overhead of adoption harder to
justify. 

> So will your university listen to the students and open a discord channel or
> was it snappchat they prefer? Sorry, hope you don't mind a joke.

Don't know, I retired and no longer work there. They did introduce
'Facebook for Business' for staff and certainly were looking at how to
incorporate various social media platforms. However, social media makes
them (administration) nervous because they cannot control it (which in
itself shows a flaw or outdated thinking within administration's
attitude).

I think some of Eli's comments are quite relevant to this discussion.
There probably needs to be more clarity about exactly what the
requirements or final goal is here. There are lots of opinions about
what would be a good solution, but less clarity regarding what precisely
those requirements are. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:41                   ` Eli Zaretskii
@ 2021-08-28  7:53                     ` tomas
  2021-08-28  8:39                       ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-28  7:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

On Sat, Aug 28, 2021 at 10:41:35AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 08:57:08 +0200
> > From: <tomas@tuxteam.de>
> > 
> > For better or worse, some MUAs [1] and corporate-influenced
> > workflows have trained a significant part of the population to
> > top-quote.
> 
> We encourage people not to top-post, but don't require them not to do
> so.  Some of them do, as you can clearly see in the archives.

I know, and I know. This is generally the stragegy in other mailing
lists, too. I was just pointing out how subtle factors can change
the general perception of a tool.

If everyone starts hammering nails with the hammer's shaft, after
a while folks will start saying "hammers suck".

[top quoting as an example "things which don't work"]

> We generally suck it up and survive.  When the fraction of these is
> not too high, it is not a problem in practice.

Yes. In mailing lists where it's more pronounced, I sometimes try
to remind people in a friendly way, but there you go.

> > On top of that, some MUAs (again, the same) don't know what a
> > Message-ID is and thread based on Subject. Resulting in monster
> > threads with the incredibly informative Subject "Re:".
> 
> That's what Rmail does, and I have yet to see a significant problem
> with it, let alone that it broke my workflows.

You mean it doesn't honour Message-ID/In-Reply-To/and References
when they are there? (Of course, in their absence it /has/ to fall
back to Subject, mail systems out there are sometimes beyond
broken).

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:04                   ` Theodor Thornhill
@ 2021-08-28  7:55                     ` Eli Zaretskii
  2021-08-28  8:05                       ` Theodor Thornhill
  2021-08-28 15:24                     ` Lars Ingebrigtsen
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  7:55 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, danflscr, emacs-devel, monnier, larsi, sir

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
> Date: Fri, 27 Aug 2021 23:04:55 +0200
> 
> ** Submitting patches by email.
> It is possible to send patches using a web interface.  It works by using
> the `prepare a patchset` button on your own clone.  So the process
> is usually:
>   - clone the repo
>   - pull it locally
>   - do the work
>   - push the work
>   - use the `prepare a patchset` button or `git format-patch`

Does it mean simply sending a patch via email is not supported?  E.g.,
I could easily create a patch without a separate clone of the
repository, using just the single clone I have already.  You seem to
describe something much more complicated, which starts with a separate
clone?

> ** Offline review
> An issue (if not already subscribed to all) can be subscribed to your
> own email and be sent to you.  The whole thing or parts of it can be
> downloaded as an mbox.

Who gets automatically subscribed to an issue?

> ** Reviewing by email
> You can use inline comments [1]

Do I just respond to an email with the patch, or do I have to use some
special format for the inline comments?

> ** Merge request creation
> Honestly I don't really understand this one...

It's about being able to submit a PR via email.

> * Code should be accompanied by documentation
> 
> This seems trivial, and can be done using the CI on patch submission
> running a job, if I understand that point correctly?
> 
> * Formatting code commits
>  Same as above

FWIW, I very much doubt these two could be automated, except for very
simple and almost trivial requirements.  How can a bot decide whether
a change requires documentation changes, and if so, which ones?  Even
our formatting of log messages is informal enough to defeat
automation.  This has to be part of patch review by humans.

> * Bug reporting
> `report-emacs-bug` can still be used, as well as clicking in the web
> ui. This is where I'm not sure about not using email.  I think you still
> need to mail the bug, opened by a mailto:

That's be a disadvantage in my book.

> I hope this helps a little.

It does, thanks a lot!



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:30                 ` Eli Zaretskii
@ 2021-08-28  7:56                   ` Theodor Thornhill
  2021-08-28  8:41                     ` Eli Zaretskii
  2021-08-28 10:18                   ` Daniel Fleischer
  1 sibling, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28  7:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dgutov, monnier, philipk, danflscr, emacs-devel



On 28 August 2021 09:30:32 CEST, Eli Zaretskii <
>The list of issues we filed with GitLab was mostly about email-based
>workflow and other relevant features, because the Web-based workflow
>was supported by GitLab already.  It sounds like we now need to
>augment that list by the requirements from the Web-based workflow,
>since SourceHut and other platforms might lack them.
>
>Would someone like to come with a list of such requirements?


Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 

The mailing of patches seems like the hardest issue to overcome from what I see people complaining about. Prettier UI/UX is also on the list. One can be learned, the other is subjective. I think the most important thing SourceHut solves is catering a little better to the one time contributing workflow than what debbugs does.

I'm really not sure what this list should look like

Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:44             ` Eli Zaretskii
@ 2021-08-28  7:57               ` tomas
  2021-08-28  8:42                 ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-28  7:57 UTC (permalink / raw)
  To: emacs-devel

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

On Sat, Aug 28, 2021 at 10:44:27AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 04:57:08 +0000 (UTC)
> > From: Werner LEMBERG <wl@gnu.org>

[...]

> > Just curious: What about using a gitlab instance (which uses the
> > GPL-compatible Expat License) on either gnu.org or an existing one
> > like gitlab.freedesktop.org?  Has this already been considered?  I
> > couldn't find this in the emacs-devel list archive.
> 
> You mean, forking it and developing our own version free of those
> problems?  That depends on the resources GNU could use for that: if
> there's a need for significant changes, we'd need to maintain that
> fork forever.

In that case, it seems advisable to understand first why this strategy
didn't work out with debbugs ("our" version seems to languish in a
state that even merging back Debian's improvements over years has
become a difficult task).

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 20:58                   ` Philip Kaludercic
  2021-08-27 21:06                     ` Sean Whitton
@ 2021-08-28  8:00                     ` Eli Zaretskii
  2021-08-28 15:20                       ` Lars Ingebrigtsen
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:00 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: danflscr, theo, emacs-devel, monnier, larsi, sir

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Theodor Thornhill <theo@thornhill.no>,  emacs-devel@gnu.org,
>   larsi@gnus.org,  monnier@iro.umontreal.ca,  danflscr@gmail.com,
>   sir@cmpwn.com
> Date: Fri, 27 Aug 2021 20:58:01 +0000
> 
> + Reduce email noise
> 
>   The mailing lists are just mailing lists, from
>   what I know the only "spam" might be CI responding with the results of
>   a test

What about automated notifications regarding a PR being merged or
issues being closed or merged or changed status?  These are a source
of constant useless noise when you subscribe to Github-based project.
Can they be filtered out, or limited to the submitter if he/she is not
an Emacs maintainer?  Or some other useful and flexible enough
filtering?

> > I tried to find answers to those questions myself, but there doesn't
> > seem to be any detailed documentation that describes the setup and
> > usage from the routine user POV (or maybe I missed it?).  I did find a
> > heads-up that "from the beta onwards, unpaid accounts will be limited
> > to read-only access to their own projects", so I wonder what that
> > means for us.  It also says that "web-based workflow for submitting
> > and reviewing patches" is still under development.
> 
> It shouldn't mean anything, if GNU decides to host their own
> instance. Otherwise, every project member would have to play to have an
> account, but I assume mailing list contributors could continue accessing
> the mailing list without any issue.

This answers the first part, but not the second.  It looks like the
Web-based workflows are still not supported well enough.

Thanks.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:55                     ` Eli Zaretskii
@ 2021-08-28  8:05                       ` Theodor Thornhill
  2021-08-28 10:16                         ` Drew DeVault
  2021-08-28 10:49                         ` Alan Third
  0 siblings, 2 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28  8:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, larsi, monnier, danflscr, philipk, sir



On 28 August 2021 09:55:18 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
>> Date: Fri, 27 Aug 2021 23:04:55 +0200
>> 
>> ** Submitting patches by email.
>> It is possible to send patches using a web interface.  It works by using
>> the `prepare a patchset` button on your own clone.  So the process
>> is usually:
>>   - clone the repo
>>   - pull it locally
>>   - do the work
>>   - push the work
>>   - use the `prepare a patchset` button or `git format-patch`
>
>Does it mean simply sending a patch via email is not supported?  E.g.,
>I could easily create a patch without a separate clone of the
>repository, using just the single clone I have already.  You seem to
>describe something much more complicated, which starts with a separate
>clone?
>

No need for a clone. Mailing a patch is enough. For the web UI thing though I think you need one.

>> ** Offline review
>> An issue (if not already subscribed to all) can be subscribed to your
>> own email and be sent to you.  The whole thing or parts of it can be
>> downloaded as an mbox.
>
>Who gets automatically subscribed to an issue?
>

Collaborators to the repos. Otherwise everyone that manually subscribe. You can follow specific issues as well.


>> ** Reviewing by email
>> You can use inline comments [1]
>
>Do I just respond to an email with the patch, or do I have to use some
>special format for the inline comments?
>

I don't know, sorry. I've just seen them.

>> ** Merge request creation
>> Honestly I don't really understand this one...
>
>It's about being able to submit a PR via email.
>

You provide PRs via mail just by sending to the correct list.


>> * Code should be accompanied by documentation
>> 
>> This seems trivial, and can be done using the CI on patch submission
>> running a job, if I understand that point correctly?
>> 
>> * Formatting code commits
>>  Same as above
>
>FWIW, I very much doubt these two could be automated, except for very
>simple and almost trivial requirements.  How can a bot decide whether
>a change requires documentation changes, and if so, which ones?  Even
>our formatting of log messages is informal enough to defeat
>automation.  This has to be part of patch review by humans.
>

I won't argue with this.

>> * Bug reporting
>> `report-emacs-bug` can still be used, as well as clicking in the web
>> ui. This is where I'm not sure about not using email.  I think you still
>> need to mail the bug, opened by a mailto:
>
>That's be a disadvantage in my book.
>

Yes it might be.

>> I hope this helps a little.
>
>It does, thanks a lot!

No problem!



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 14:17     ` Daniel Martín
@ 2021-08-28  8:11       ` Eli Zaretskii
  2021-08-28 13:04         ` SourceHut for Emacs (was: Gitlab Migration) Stefan Monnier
  2021-08-28 14:07         ` Gitlab Migration Daniel Martín
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:11 UTC (permalink / raw)
  To: Daniel Martín; +Cc: danflscr, emacs-devel

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: danflscr@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 16:17:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >
> > Are you asking about contributors or about the core maintainers?
> > E.g., you mention interaction with bug reports, but AFAIK contributors
> > have only one kind of interaction here: when they submit a report.  So
> > I wonder whether I understand your questions.
> 
> The core maintainers: The people that usually check for new bug reports
> and act on them, classify them by priority and see if they block a
> release, review and commit any patches that are sent to fix the bugs,
> etc.

I do almost everything inside Emacs.  Once I've got bug report in
Emacs, as part of reading email, I use the Emacs facilities to work on
it: the code inspection features like M-. and "M-x grep", Lisp
evaluation, Help commands, etc.  I do use the debbugs package, albeit
rarely, mainly when I need to work on large numbers of bugs.

For search, I use the Debbugs Web form (but I rarely need that,
either); I also have email search set up, but that's also rarely
needed.

For code review, it is important for me to be able to do the following
basic tasks efficiently while reviewing the patch:

  . find code in Emacs
  . copy code from Emacs's sources to the review text
  . spell-check what I write and fix typos
  . run Git commands, including forensics and patch application
  . read past discussions of the same or related issues

Does this answer your question?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:03   ` Eli Zaretskii
@ 2021-08-28  8:12     ` Yuchen Pei
  2021-08-28  8:45       ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Yuchen Pei @ 2021-08-28  8:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: danflscr, rms, emacs-devel

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Fri, 27 Aug 2021 22:59:20 -0400
>> Cc: emacs-devel@gnu.org
>> 
>> notabug.org and sr.ht are considerably better, by our ethical
>> evaluation standards.
>
> Would someone please evaluate notabug.org wrt our expectations, 
> and
> post a summary?  TIA.

There was already some evaluation:

https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-03/msg00052.html
https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-06/msg00036.html
https://libreplanet.org/wiki/Notabug

Not sure if it was conclusive though.

-- 
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
           <https://ypei.me/assets/ypei-pubkey.txt>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:53                     ` tomas
@ 2021-08-28  8:39                       ` Eli Zaretskii
  2021-08-28  8:43                         ` tomas
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:39 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

> Date: Sat, 28 Aug 2021 09:53:55 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > > On top of that, some MUAs (again, the same) don't know what a
> > > Message-ID is and thread based on Subject. Resulting in monster
> > > threads with the incredibly informative Subject "Re:".
> > 
> > That's what Rmail does, and I have yet to see a significant problem
> > with it, let alone that it broke my workflows.
> 
> You mean it doesn't honour Message-ID/In-Reply-To/and References
> when they are there?

It does, but not for threading purposes.  Rmail's equivalent of
threading commands are rmail-next-same-subject and
rmail-previous-same-subject; the names of those commands already tell
you what it does.  It doesn't have any other notion of threads, AFAIK,
and doesn't allow display of messages by threads, except grouping them
by Subject.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:56                   ` Theodor Thornhill
@ 2021-08-28  8:41                     ` Eli Zaretskii
  2021-08-28  9:00                       ` Theodor Thornhill
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:41 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, emacs-devel, danflscr, monnier, dgutov

> Date: Sat, 28 Aug 2021 09:56:45 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>  danflscr@gmail.com, emacs-devel@gnu.org
> 
> >Would someone like to come with a list of such requirements?
> 
> 
> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 

I think these are basically the various important aspects of the PR
Web-based workflow.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:57               ` tomas
@ 2021-08-28  8:42                 ` Eli Zaretskii
  2021-08-28  8:47                   ` tomas
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:42 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

> Date: Sat, 28 Aug 2021 09:57:34 +0200
> From: <tomas@tuxteam.de>
> 
> > You mean, forking it and developing our own version free of those
> > problems?  That depends on the resources GNU could use for that: if
> > there's a need for significant changes, we'd need to maintain that
> > fork forever.
> 
> In that case, it seems advisable to understand first why this strategy
> didn't work out with debbugs ("our" version seems to languish in a
> state that even merging back Debian's improvements over years has
> become a difficult task).

Is it really hard to understand?  The usual reason is availability of
resources.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:39                       ` Eli Zaretskii
@ 2021-08-28  8:43                         ` tomas
  0 siblings, 0 replies; 525+ messages in thread
From: tomas @ 2021-08-28  8:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

On Sat, Aug 28, 2021 at 11:39:35AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 09:53:55 +0200
> > From: tomas@tuxteam.de

[...]

> > You mean [Rmail] doesn't honour Message-ID/In-Reply-To/and References
> > when they are there?
> 
> It does, but not for threading purposes.  Rmail's equivalent of
> threading commands are rmail-next-same-subject and
> rmail-previous-same-subject; [...]  It doesn't have any other
> notion of threads, AFAIK [...]

Thanks for the clarification :)

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:12     ` Yuchen Pei
@ 2021-08-28  8:45       ` Eli Zaretskii
  0 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:45 UTC (permalink / raw)
  To: Yuchen Pei; +Cc: danflscr, rms, emacs-devel

> From: Yuchen Pei <hi@ypei.me>
> Cc: rms@gnu.org, danflscr@gmail.com, emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 18:12:36 +1000
> 
> >> notabug.org and sr.ht are considerably better, by our ethical
> >> evaluation standards.
> >
> > Would someone please evaluate notabug.org wrt our expectations, 
> > and
> > post a summary?  TIA.
> 
> There was already some evaluation:
> 
> https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-03/msg00052.html
> https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-06/msg00036.html
> https://libreplanet.org/wiki/Notabug

Thanks, but that's not what I meant.  I meant the evaluation wrt to
the requirements the Emacs project has to such a platform.  The same
requirements we were discussing regarding GitLab and SourceHut.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:42                 ` Eli Zaretskii
@ 2021-08-28  8:47                   ` tomas
  0 siblings, 0 replies; 525+ messages in thread
From: tomas @ 2021-08-28  8:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

On Sat, Aug 28, 2021 at 11:42:41AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 09:57:34 +0200
> > From: <tomas@tuxteam.de>
> > 
> > > [...] forking [Gitlab] and developing our own version free of those
> > > problems? [...]

> > In that case, it seems advisable to understand first why this strategy
> > didn't work out with debbugs [...]

> Is it really hard to understand?  The usual reason is availability of
> resources.

Yes, perhaps. But then, Gitlab could be potentially more costly (more
code, faster cycles these days, etc.).

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:53                   ` Tim Cross
@ 2021-08-28  8:52                     ` Eli Zaretskii
  2021-08-28  9:10                       ` tomas
  2021-08-28  9:33                     ` Arthur Miller
  2021-08-28 16:11                     ` [External] : " Drew Adams
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:52 UTC (permalink / raw)
  To: Tim Cross; +Cc: danflscr, arthur.miller, emacs-devel

> From: Tim Cross <theophilusx@gmail.com>
> Date: Sat, 28 Aug 2021 17:53:34 +1000
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> Despite what others have claimed, the security problems with email have
> NOT been addressed. It is still one of the major vectors for
> compromising access via social engineering, major vector for infection
> from ransomeware, frequent source of privacy breeches and a common means
> used to get sensitive data out of an organisation.

And other means of communications aren't?  Are there _any_ means that
are immune to these attacks?

> For younger people, I suspect part of it is just a perception of email
> as being old and outdated and not fitting as well with their 'style' of
> communication, which tends to be about short messages and group chat in
> near 'real time'.

Email is almost as real-time as the other means nowadays.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:45                 ` Eli Zaretskii
@ 2021-08-28  8:53                   ` Arthur Miller
  0 siblings, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  8:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, emacs-devel, danflscr, larsi, dgutov

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: dgutov@yandex.ru,  philipk@posteo.net,  danflscr@gmail.com,
>>   larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 03:51:40 +0200
>> 
>> >> and debbugs package for browsing bugs directly from Emacs?
>> >
>> > The debbugs package has several non-trivial dependencies, like email,
>> > and is probably not the first or the second thing newcomers should be
>> > messing with.
>> 
>> Maybe, but if somoeone is developer who would like to send in patch to Emacs
>> than they can probably setup email? Newcomer to Emacs dev, does not mean
>> newcomer to computing.
>
> The main purpose of the Emacs debbugs package is not to send patches.
> Sending patches when you have email set up is trivial and doesn't need
> the debbugs package.

About debbugs, I meant for exploration of bugs. Someone mentioned that web based
interface offers "issues" lists where people easily can see if their issue is
already repported or not. My argument is that debbugs with Emacs interface
offers as easy such interface. Though search is not as easy since Emacs fetches
data only on request. One can use C-s to search between titles in debbugs
buffer, but it does not seem to possible to search in-depth in articles, at
least I don't know how. I guess I would have to download entire database to the
harddrive. I don't understand why would peopel prefer to search issues in web
browser, if they can do it faster in Emacs. We just need better interface.

>> What about automating it for them?
>> 
>> Is this too wild: when someone signs FSF copyrights assignement, create
>> automatic "development mail account", which will work only to send and recieve
>> emails between certain addresses, the person and those used for Emacs
>> devs? We could then write a small pacakge to auto-setup persons account in
>> his/her Emacs that would work for bug repporting, debbugs, sending patches etc.
>> 
>> Limitiation because I guess FSF/GNU does not have resources to host free email
>> accounts for everyone.
>
> You mean, set up email account on GNU servers?  That's problematic in
> more than one sense, some of which you mention above.
>
> And what would be the advantages?

The advantage would be that we could have a package in Emacs that sets
everythign up for making it easy for newcomers to contribute so they don't need
to bother with setuing up mail to work with emacs. We could also possibly create
more github/gitlab similar workflow in emacs directly if people could
participate in email-based workflow out of the box so to say. It is lots of
"could" I am aware of.

>> We could then abstract parts of PR based worklfow on top of email.
>
> For people who are familiar with, and used to, the PR workflow using
> Web forms, I don't think this would be an advantage.  The main purpose
> of moving to a service we are discussing is to provide a familiar UI
> to those contributors, with a special emphasis on occasional
> contributors who don't have time, or don't want, to learn a new UI
> just to contribute to Emacs.

Yes, but sh does not look familiar to people who are using github or gitlab. The
risk is also, that you may invest a lot of time, just to find that people are
still opposing because they are taken outside their common environment, required
to create account on new service, adapt to different workflow etc.

Unique selling point of Emacs is integration. I mean, I don't need to leave
Emacs to contribute to Emacs at all. I use same shortcuts for everything, same
familiar interface etc. That's Emacs strength.

Some people are not familiar with the concept, but it can be simplified. Maybe
we need to work better on emphasizing Emacs strengths and help people to use
emacs more effectively.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:41                     ` Eli Zaretskii
@ 2021-08-28  9:00                       ` Theodor Thornhill
  2021-08-28  9:24                         ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28  9:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dgutov, monnier, philipk, danflscr, emacs-devel



On 28 August 2021 10:41:01 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 28 Aug 2021 09:56:45 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>>  danflscr@gmail.com, emacs-devel@gnu.org
>> 
>> >Would someone like to come with a list of such requirements?
>> 
>> 
>> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 
>
>I think these are basically the various important aspects of the PR
>Web-based workflow.

If that's the case I'd say it is covered. But it is different. And in my experience people have a hard time with different. But if inching a little closer to what GitHub does it our goal, then I'd say SourceHut covers it. If making it more accessible to webfolks is the goal, we will get more than halfway. Is that enough? No idea.

People can contribute without using email.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:52                     ` Eli Zaretskii
@ 2021-08-28  9:10                       ` tomas
  2021-08-28  9:54                         ` Tim Cross
  0 siblings, 1 reply; 525+ messages in thread
From: tomas @ 2021-08-28  9:10 UTC (permalink / raw)
  To: emacs-devel

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

On Sat, Aug 28, 2021 at 11:52:48AM +0300, Eli Zaretskii wrote:
> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Sat, 28 Aug 2021 17:53:34 +1000
> > Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> > 
> > Despite what others have claimed, the security problems with email have
> > NOT been addressed. It is still one of the major vectors for
> > compromising access via social engineering [...]

> And other means of communications aren't?  Are there _any_ means that
> are immune to these attacks?

Yes, this made me wonder a bit, too, at how diverse perceptions
can be. A code execution platform executing random scripts off
the internet (aka Web browser) beats mail any day, in my view.

Smartphone operating systems with their app "ecosystems" are
fashioned after the same model.

I'd have to see some statistics to support Tim's "major vector"
assertion above.

Cheers
 - t

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  9:00                       ` Theodor Thornhill
@ 2021-08-28  9:24                         ` Eli Zaretskii
  2021-08-28  9:51                           ` Theodor Thornhill
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  9:24 UTC (permalink / raw)
  To: Theodor Thornhill; +Cc: philipk, emacs-devel, danflscr, monnier, dgutov

> Date: Sat, 28 Aug 2021 11:00:36 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>  danflscr@gmail.com, emacs-devel@gnu.org
> 
> >> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 
> >
> >I think these are basically the various important aspects of the PR
> >Web-based workflow.
> 
> If that's the case I'd say it is covered.

Dmitry seems to think otherwise, and he gave examples of such
features, to which you agreed.

> But it is different. And in my experience people have a hard time with different. But if inching a little closer to what GitHub does it our goal, then I'd say SourceHut covers it. If making it more accessible to webfolks is the goal, we will get more than halfway. Is that enough? No idea.

We need to established whether it's enough, and if it isn't, either
look for a better alternative, or somehow make sure SourceHut gets
closer.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  5:57     ` Eli Zaretskii
@ 2021-08-28  9:25       ` Alan Third
  2021-08-28  9:40         ` Eli Zaretskii
  2021-08-28 21:42         ` Basil L. Contovounesios
  0 siblings, 2 replies; 525+ messages in thread
From: Alan Third @ 2021-08-28  9:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: mardani29, danflscr, Stefan Monnier, emacs-devel

On Sat, Aug 28, 2021 at 08:57:39AM +0300, Eli Zaretskii wrote:
> > - I find it a big difficult to classify bugs.  I'm not sure exactly what
> >   I'd like, and maybe some of it can be done via tags and other things
> >   already, but I think I'd like it if bugs could be "assigned" to persons
> >   and/or to files and/or to "subsystems", and maybe even combine this
> >   with ways to describe relationships between those things (so the
> >   search tools can known that a given file belongs to a particular
> >   subsystem, for example).
> 
> We should first come up with a meaningful classification that would
> help in handling the bugs.  Only then we can talk about the
> implementation.  I don't have any practical suggestion for
> classification ATM, and frankly, as long as we have only a handful of
> people doing this, it doesn't sound very important.

I occasionally use the usertags feature to tag bug reports as for NS,
which is very helpful for finding relevant bugs. Someone else was
doing it before me, and not all NS bugs are tagged. I struggle to
remember how to use the email-based admin for debbugs, so I only ever
tag them when I'm using the emacs debbugs UI, which is much less often
than I use my MUA.

Not relevant to this discussion, but it has just occurred to me that
since I write all my emails in Emacs it should be possible to create
some sort of system for semi-automatically inserting debbugs commands
into the current email body.
-- 
Alan Third



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:53                   ` Tim Cross
  2021-08-28  8:52                     ` Eli Zaretskii
@ 2021-08-28  9:33                     ` Arthur Miller
  2021-08-28 16:11                     ` [External] : " Drew Adams
  2 siblings, 0 replies; 525+ messages in thread
From: Arthur Miller @ 2021-08-28  9:33 UTC (permalink / raw)
  To: Tim Cross; +Cc: Daniel Fleischer, emacs-devel

Tim Cross <theophilusx@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>>
>> I understand, but that can also be interpretted as if they prefer mail as
>> they getting more experienced.
>
> Yes, I already pointed that out and said we won't know until more time
> has passed. 
>
>> I also don't really understand what is problem
>> with emails. Smartphones have almost removed distinction between a so called an
>> instant message and and email. Email has become just yet another messaging
>> media.
>>
>
> Some of it is about ensuring all necessary information is included. In
> many 'business' processes, email is a problem because people neglect to
> include crucial information in the message. If on the other hand, they
> are required to fill in a form, then mandatory or important information
> can be gathered and the content will be in a set format, enabling easier
> automation of processing.
>
> Despite what others have claimed, the security problems with email have
> NOT been addressed. It is still one of the major vectors for
> compromising access via social engineering, major vector for infection
> from ransomeware, frequent source of privacy breeches and a common means
> used to get sensitive data out of an organisation. Even having encrypted
> messages is overly complex for most users and a nightmare to administer
> for large organisations. Some of these issues can be partially mitigated
> through training/education and various technologies, but these tend to
> significantly increase the cost and administration overheads and often
> make the service less convenient for users. There is also an element of
> it all being 'too hard' (from an administration perspective). 
>
> For younger people, I suspect part of it is just a perception of email
> as being old and outdated and not fitting as well with their 'style' of
> communication, which tends to be about short messages and group chat in
> near 'real time'.

That can be the case. Mail is not so good group conversations, indeed.

>> What I have suggested in several comments by now, is that it is maybe possible
>> to tuck git workflow on existing mail workflow. Maybe some tasks could be
>> automated I don't know.
>>
>
> I'm sure we could use git facilities to enhance the existing workflows,
> but that isn't what people are asking for. Those using the existing
> email based workflows are not the ones suggesting adoption of more
> github/gitlab type functionality. I get the impression that those who
> use the existing workflows are quite happy with the current situation.
> this is what makes the suggestion of sourceHut as a solution uncertain
> as it isn't clear it would provide the web UI facilities being asked for
> and may only add a little sugar to the existing workflows, which may
> make the effort and change management overhead of adoption harder to
> justify. 

What I mean, is that we could maybe masquerade mail worfklow as git worfklow so
those that prefer git workflow can feel somewhat at home. While nobody has speak
of it, or I have missed it, it can happen that sourceHut is not what those
hypotetical developers ask for. It might be that they come up wit other
arguments and refute sourceHut as yet another burden they need to overcome. I
feel that many would prefer platform they are already in, i.e. github or gitlab,
becuase everybody else is there, they work is exposed to the public
(self-promotion), they already contribute to other projects there, etc. Does not
have to be so, but I would leave an option that it might be case too.

>> So will your university listen to the students and open a discord channel or
>> was it snappchat they prefer? Sorry, hope you don't mind a joke.
>
> Don't know, I retired and no longer work there. They did introduce
> 'Facebook for Business' for staff and certainly were looking at how to
'Facebook for Business' - my company use that too. I work for a large company
that is established over entire country and worldwide, so they have installed
Workplace (as facebook for business is called) and switched everything to
facebook.

> incorporate various social media platforms. However, social media makes
> them (administration) nervous because they cannot control it (which in
> itself shows a flaw or outdated thinking within administration's
> attitude).
>
> I think some of Eli's comments are quite relevant to this discussion.
> There probably needs to be more clarity about exactly what the
> requirements or final goal is here. There are lots of opinions about
> what would be a good solution, but less clarity regarding what precisely
> those requirements are. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  9:25       ` Alan Third
@ 2021-08-28  9:40         ` Eli Zaretskii
  2021-08-28 21:42         ` Basil L. Contovounesios
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28  9:40 UTC (permalink / raw)
  To: Alan Third; +Cc: mardani29, danflscr, monnier, emacs-devel

> Date: Sat, 28 Aug 2021 10:25:31 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org,
> 	danflscr@gmail.com, mardani29@yahoo.es
> 
> Not relevant to this discussion, but it has just occurred to me that
> since I write all my emails in Emacs it should be possible to create
> some sort of system for semi-automatically inserting debbugs commands
> into the current email body.

A debbugs command is very simple text, so it should be almost trivial
to write a command to add it to a message being composed.  Definitely
so for a single command such as usertags.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  9:24                         ` Eli Zaretskii
@ 2021-08-28  9:51                           ` Theodor Thornhill
  0 siblings, 0 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28  9:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dgutov, monnier, philipk, danflscr, emacs-devel



On 28 August 2021 11:24:12 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 28 Aug 2021 11:00:36 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>>  danflscr@gmail.com, emacs-devel@gnu.org
>> 
>> >> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 
>> >
>> >I think these are basically the various important aspects of the PR
>> >Web-based workflow.
>> 
>> If that's the case I'd say it is covered.
>
>Dmitry seems to think otherwise, and he gave examples of such
>features, to which you agreed.
>

I agreed on some of it yes, and demonstrated where he was wrong. The things I noted as missing it mostly different:
- editing a comment require a new email
- subsequent iterations on a patch isn't squashed in the web UI

The last one may be a bummer, but not sure if it is. In my opinion this shouldn't tester contributions, but who knows. 

>> But it is different. And in my experience people have a hard time with different. But if inching a little closer to what GitHub does it our goal, then I'd say SourceHut covers it. If making it more accessible to webfolks is the goal, we will get more than halfway. Is that enough? No idea.
>
>We need to established whether it's enough, and if it isn't, either
>look for a better alternative, or somehow make sure SourceHut gets
>closer.

Drew is very responsive, and I think getting input on what a real, old Foss projects needs would be important. Can't speak on his behalf though



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  9:10                       ` tomas
@ 2021-08-28  9:54                         ` Tim Cross
  0 siblings, 0 replies; 525+ messages in thread
From: Tim Cross @ 2021-08-28  9:54 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel


<tomas@tuxteam.de> writes:

> [[PGP Signed Part:Undecided]]
> On Sat, Aug 28, 2021 at 11:52:48AM +0300, Eli Zaretskii wrote:
>> > From: Tim Cross <theophilusx@gmail.com>
>> > Date: Sat, 28 Aug 2021 17:53:34 +1000
>> > Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
>> > 
>> > Despite what others have claimed, the security problems with email have
>> > NOT been addressed. It is still one of the major vectors for
>> > compromising access via social engineering [...]
>
>> And other means of communications aren't?  Are there _any_ means that
>> are immune to these attacks?
>
> Yes, this made me wonder a bit, too, at how diverse perceptions
> can be. A code execution platform executing random scripts off
> the internet (aka Web browser) beats mail any day, in my view.
>
> Smartphone operating systems with their app "ecosystems" are
> fashioned after the same model.
>
> I'd have to see some statistics to support Tim's "major vector"
> assertion above.
>

There are lots of reports, analysis and case studies released by a
number of reputable security firms. Just do a basic google and you will
find plenty of evidence and statistics. Talk to any reputable security
firm and ask them what their experiences are. Most countries have some
form of government cyber security body - check any of them and you will
likely find statistics which show the percentage of major security
incidents where email was the initial vector used.

For example, NIST has a whole bunch of documents and frameworks dealing
solely with email security. Quoting from the NIST Cybersecurity
Framework and Email compliance document from August 25 2021
https://www.tessian.com/blog/nist-cybersecurity-framework-and-email-security/ 

"Ransomware is becoming the most severe cybersecurity threat in the
current threat landscape. Because many, if not most, ransomware attacks
start via email, improving your organization’s email security and its
ransomware defense posture go hand-in-hand."

Frameworks like the NIST framework can go a long way to improving the
security of email. However, the big problem is the human factor.
Companies are spending huge amounts on training and education of staff
to make them less vulnerable to social engineering, but this has high
costs and is difficult to maintain. Often, the business response is to
reduce or minimise the exposure by adopting alternative solutions. It
isn't an argument about how good the technology is or how it can be more
efficient than web based alternatives or case studies showing how a team
using email was more efficient than one using product X. This is largely
about risk mitigation, streamlining administration, reducing dependency
on in-house technical skills and avoiding negative PR. Like it or not,
email has got a sour taste for management in many corporations and this
is driving the change. Focusing on the technical aspects is misguided as
it fails to recognise the real drivers behind the shift. 

To be honest, I'm a little surprised this seems to be 'news', but then
again, I spent the last 10 years working in the security space and that
has probably skewed my view on what is 'known' more broadly. Attend
enough conferences, seminars and workshops and you soon forget what you
know is not always general knowledge. 

As to the question of other communication channels also having security
vulnerabilities - yes of course. No system is 100% secure. However, many
of the alternatives being proposed in many companies allow strong or
more effective mitigation strategies. In a large part this is due to
greater control over who can inject information into the system, greater
control over what users can do and more control over keeping core
components up-to-date. There is also the 'obscurity' aspect - Things
like ransomeware are a numbers game - the more people you can target,
the higher chance of success. With email, it is easy because you just
craft an appropriate email with the right payload. With other
communications channels, you have to be more specific and target
vulnerabilities within that specific product to get your payload into
the system and then get it delivered to the user's browser (or app or
whatever). Basically, the ROI isn't as good.

Mobile devices and apps are definitely a significant challenge and
increasingly so as time passes. However, I never stated these other
channels are secure or without problems. It is almost certainly the case
that if a majority of companies moved away from email to other
platforms, those platforms will begin to be targeted more because they
will provide a higher ROI. However, they will also likely require a
higher skill set level than the current situation with email. This too
will change as more 'canned' exploits become available in the market,
but that will take time. Look at the macOS platform. There are still
lots of people who believe that platform is not vulnerable to viruses.
In reality, it is probably just as vulnerable as modern MS Windows, but
the ROI for development of macOS viruses is much lower than for Windows.
It is a numbers game. 

On a side note, I was just talking to my daughter - she is 20. I asked
her about her use of email. She showed me the email 'icon' on her phone.
Her current count of unread email messages is 8400! I asked her how many
of her friends email addresses she knew. She said 1. 

I cannot convince anyone really. All I can do is put forward my view and
experience. After leaving my last permanent position, I spent a few
years consulting, mainly in the Identity and Access management area. I
know from speaking to many executives in medium and large organisations,
email is one of their highest concerns and they are actively moving to
reduce dependency and incorporation of email in core business processes.
I know from talking to my children (one 20, the other 25) that email
doesn't even get considered in their communications and I know from the
last project I worked at in the University that younger students are not
at all interested in email.

Personally, I love email. As a blind programmer, it is much more
accessible than any of the alternatives. I've had an email account since
the 80s. I love the power of email based workflows. However, this makes
no difference. If Emacs wants to encourage contributions from younger
users and wants to appear relevant, we probably need to seriously
consider providing alternatives to a community centred around email.
This doesn't mean we have to replace existing channels, but instead
add/augment them with additional interfaces.





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:05                       ` Theodor Thornhill
@ 2021-08-28 10:16                         ` Drew DeVault
  2021-08-28 12:09                           ` Daniel Fleischer
  2021-08-28 10:49                         ` Alan Third
  1 sibling, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-28 10:16 UTC (permalink / raw)
  To: Theodor Thornhill, Eli Zaretskii
  Cc: philipk, larsi, danflscr, monnier, emacs-devel

Hi! This thread is on my radar but I am at an event so I am a bit scarce
on time. I will answer any questions in thorough detail tomorrow or
Monday. In the meantime, a small summary based on what I've acertained
from reading this thread:

First, we would be very pleased to host emacs on our service, or with
our software on your own infrastructure. It should more-or-less work
with everyone's existing workflows, given that emacs is an
email-oriented project, and over time we are developing an improved
web-based experience which should allow more and more users access to
emacs development over time without necessarily requiring the
maintainers or those who prefer their email-oriented workflow to have to
change their workflow to accomodate a platform like GitLab. We should
also rate quite highly in terms of free-as-in-freedom, since the entire
service is free software, mostly AGPL.

Regarding payment, payment is expected of those who *own* resources on
SourceHut, for the hosted version only. If you host it yourself, you can
configure these settings per your needs. So, for instance, the person
who has control over the emacs mailing lists would be expected to have a
paid account. However, contributors, i.e. someone who sends a patch to
that list, are not expected to pay. In fact, you don't need an account
to participate at all, much like GNU Mailman (which I think you're using
now?)

The bug tracker is indeed a bit different, but we are planning
improvements which will make it more email-oriented, by basically making
it a frontend for the mailing lists similarly to how debbugs works.

If you have any other questions, drop them in my inbox and I'll answer
as soon as I'm able. Cheers!



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  7:30                 ` Eli Zaretskii
  2021-08-28  7:56                   ` Theodor Thornhill
@ 2021-08-28 10:18                   ` Daniel Fleischer
  2021-08-28 11:43                     ` Philip Kaludercic
  1 sibling, 1 reply; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-28 10:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, emacs-devel, Theodor Thornhill, monnier, dgutov

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

Eli Zaretskii [2021-08-28 Sat 10:30]  wrote:

> The list of issues we filed with GitLab was mostly about email-based
> workflow and other relevant features, because the Web-based workflow
> was supported by GitLab already.  It sounds like we now need to
> augment that list by the requirements from the Web-based workflow,
> since SourceHut and other platforms might lack them.
>
> Would someone like to come with a list of such requirements?

Here are some points:

1. Issues page; collection of bug report, feature suggestions and
general discussions, with or without code commits associated with them.
Ability to tag and search, including closed issues. Ability to define
"projects" which are short term goals and associate issues and PR with
them. Ability to assign issues to specific users. Ability to pin issues
at the top for easy discoverability.

1. PR page; since anyone can clone the project locally and make
modifications, PR page is a list of suggested changes, merges between
some branch in contributors' "local" projects and the original (usually
master) branch. Technically it's a patch. Ability to view the diff.
Ability to have discussions around the PR. Ability to continue modifying
the suggested code by all parties and the diff is kept up to date.
Indications of CI tests pass/fail. ADVANCED: ability to do quick code
edits and commits on the web.

1. Code exploration; view code with syntax highlighting for most file
types. Being able to jump to function definitions and usages (at least
in github). Many people explore code in the web before possibly cloning
it locally so it's an important QOL feature.

*Daniel Fleischer*

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:05                       ` Theodor Thornhill
  2021-08-28 10:16                         ` Drew DeVault
@ 2021-08-28 10:49                         ` Alan Third
  2021-08-28 11:42                           ` Theodor Thornhill
  1 sibling, 1 reply; 525+ messages in thread
From: Alan Third @ 2021-08-28 10:49 UTC (permalink / raw)
  To: Theodor Thornhill
  Cc: philipk, danflscr, emacs-devel, sir, monnier, Eli Zaretskii, larsi

On Sat, Aug 28, 2021 at 10:05:50AM +0200, Theodor Thornhill wrote:
> 
> 
> On 28 August 2021 09:55:18 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Theodor Thornhill <theo@thornhill.no>
> >> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
> >>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
> >> Date: Fri, 27 Aug 2021 23:04:55 +0200
> >> 
> >> ** Submitting patches by email.
> >> It is possible to send patches using a web interface.  It works by using
> >> the `prepare a patchset` button on your own clone.  So the process
> >> is usually:
> >>   - clone the repo
> >>   - pull it locally
> >>   - do the work
> >>   - push the work
> >>   - use the `prepare a patchset` button or `git format-patch`
> >
> >Does it mean simply sending a patch via email is not supported?  E.g.,
> >I could easily create a patch without a separate clone of the
> >repository, using just the single clone I have already.  You seem to
> >describe something much more complicated, which starts with a separate
> >clone?
> >
> 
> No need for a clone. Mailing a patch is enough. For the web UI thing though I think you need one.

Out of interest, we currently work by attaching patches to emails but
I understand the usual "git" way of doing it is by sending the patch
directly AS an email. Is that something we'd have to do differently?

-- 
Alan Third



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 10:49                         ` Alan Third
@ 2021-08-28 11:42                           ` Theodor Thornhill
  2021-08-28 11:47                             ` Jean-Christophe Helary
  0 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28 11:42 UTC (permalink / raw)
  To: Alan Third
  Cc: Eli Zaretskii, emacs-devel, larsi, monnier, danflscr, philipk, sir

Alan Third <alan@idiocy.org> writes:

[...]

> Out of interest, we currently work by attaching patches to emails but
> I understand the usual "git" way of doing it is by sending the patch
> directly AS an email. Is that something we'd have to do differently?
>


Good point.  I tried this right now, and it seems like the patch as an
attachment doesn't work as well... You have to manually view the raw
patch by expanding the details section then `download raw message`


You can see what it looks like here:
https://lists.sr.ht/~theo/public-inbox

Two patches are sent here. The newest is with `git send-email <file>`,
the other is as an attachment.  I think this is a shortcoming in
sourcehut, absolutely.  It must be solvable still, though.

--
Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 10:18                   ` Daniel Fleischer
@ 2021-08-28 11:43                     ` Philip Kaludercic
  2021-08-28 11:45                       ` Theodor Thornhill
  0 siblings, 1 reply; 525+ messages in thread
From: Philip Kaludercic @ 2021-08-28 11:43 UTC (permalink / raw)
  To: Daniel Fleischer
  Cc: Eli Zaretskii, emacs-devel, Theodor Thornhill, monnier, dgutov

Daniel Fleischer <danflscr@gmail.com> writes:

> 1. Code exploration; view code with syntax highlighting for most file
> types. Being able to jump to function definitions and usages (at least
> in github). Many people explore code in the web before possibly cloning
> it locally so it's an important QOL feature.

I think this is supported in principle, one would have to see what is
necessary for this to work with Elisp too.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 11:43                     ` Philip Kaludercic
@ 2021-08-28 11:45                       ` Theodor Thornhill
  2021-08-28 12:25                         ` Philip Kaludercic
  2021-08-28 13:49                         ` Dmitry Gutov
  0 siblings, 2 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28 11:45 UTC (permalink / raw)
  To: Philip Kaludercic, Daniel Fleischer
  Cc: Eli Zaretskii, dgutov, monnier, emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

> Daniel Fleischer <danflscr@gmail.com> writes:
>
>> 1. Code exploration; view code with syntax highlighting for most file
>> types. Being able to jump to function definitions and usages (at least
>> in github). Many people explore code in the web before possibly cloning
>> it locally so it's an important QOL feature.
>
> I think this is supported in principle, one would have to see what is
> necessary for this to work with Elisp too.
>


You can absolutely read the repo, but the newish feature of github where
some languages are backed by lsp is most likely not on the roadmap

--
Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 11:42                           ` Theodor Thornhill
@ 2021-08-28 11:47                             ` Jean-Christophe Helary
  2021-08-28 11:56                               ` Theodor Thornhill
  0 siblings, 1 reply; 525+ messages in thread
From: Jean-Christophe Helary @ 2021-08-28 11:47 UTC (permalink / raw)
  To: Theodor Thornhill
  Cc: Alan Third, danflscr, philipk, Emacs Devel, sir, Stefan Monnier,
	Lars Ingebrigtsen, Eli Zaretskii

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

> On Aug 28, 2021, at 20:42, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> Alan Third <alan@idiocy.org> writes:
> 
>> Out of interest, we currently work by attaching patches to emails but
>> I understand the usual "git" way of doing it is by sending the patch
>> directly AS an email. Is that something we'd have to do differently?
> 
> Good point.  I tried this right now, and it seems like the patch as an
> attachment doesn't work as well... You have to manually view the raw
> patch by expanding the details section then `download raw message`

Nice to see another sr-ht user here :-)

https://drewdevault.com/2018/07/02/Email-driven-git.html

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/


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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 11:47                             ` Jean-Christophe Helary
@ 2021-08-28 11:56                               ` Theodor Thornhill
  2021-08-28 12:09                                 ` Drew DeVault
  0 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28 11:56 UTC (permalink / raw)
  To: Jean-Christophe Helary
  Cc: Alan Third, Eli Zaretskii, Emacs Devel, Lars Ingebrigtsen,
	Stefan Monnier, danflscr, philipk, sir

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Aug 28, 2021, at 20:42, Theodor Thornhill <theo@thornhill.no> wrote:
>> 
>> Alan Third <alan@idiocy.org> writes:
>> 
>>> Out of interest, we currently work by attaching patches to emails but
>>> I understand the usual "git" way of doing it is by sending the patch
>>> directly AS an email. Is that something we'd have to do differently?
>> 
>> Good point.  I tried this right now, and it seems like the patch as an
>> attachment doesn't work as well... You have to manually view the raw
>> patch by expanding the details section then `download raw message`
>
> Nice to see another sr-ht user here :-)
>
likewise :)

> https://drewdevault.com/2018/07/02/Email-driven-git.html
>

Though I agree in general with what that blog post states, it isn't
really pragmatic enough, imo.  If you want to optimize for contributions
you have to allow several workflows.  Sending a patch as an attachment
is, imo a little less daunting than setting up smtp and friends to allow
for a typo correction contribution (which is how many people first start
contributing).  I asked Phil Hagelberg how he handles things in fennel,
which is one of sourcehuts flagships if I'm not mistaken:

https://icosahedron.website/@technomancy/106830388735139937

--
Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 10:16                         ` Drew DeVault
@ 2021-08-28 12:09                           ` Daniel Fleischer
  2021-08-28 12:29                             ` Drew DeVault
  2021-08-28 13:26                             ` Jean-Christophe Helary
  0 siblings, 2 replies; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-28 12:09 UTC (permalink / raw)
  To: Drew DeVault
  Cc: philipk, Theodor Thornhill, emacs-devel, monnier, Eli Zaretskii, larsi

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

Hi Drew,

If you're here, a quick question about UX; starting from a project's
main page, e.g. <https://sr.ht/~lattis/muon/>, I notice going to either
the "source", "mailing-list" or "tickets" pages takes you to other
subdomains where there's no way to go back using the UI. I think there
should be a way to go back to a project's main page without using
"back". 

Thanks, 

*Daniel Fleischer*

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 11:56                               ` Theodor Thornhill
@ 2021-08-28 12:09                                 ` Drew DeVault
  0 siblings, 0 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-28 12:09 UTC (permalink / raw)
  To: Theodor Thornhill, Jean-Christophe Helary
  Cc: Alan Third, danflscr, philipk, Emacs Devel, Stefan Monnier,
	Lars Ingebrigtsen, Eli Zaretskii

We do expect git send-email, but as a good practice, and I don't think
it's reasonable to support it as an attachment instead. However, we have
sent many usability improvements to git upstream and I have written an
interactive git send-email tutorial, which is recommended by the git
book and by the Linux kernel documentation:

https://git-send-email.io



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:31     ` Arthur Miller
@ 2021-08-28 12:23       ` Stefan Monnier
  0 siblings, 0 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-28 12:23 UTC (permalink / raw)
  To: Arthur Miller; +Cc: Daniel Martín, Daniel Fleischer, emacs-devel

> I think storing it in Git itself would be very nice indeed.
>
> I wonder if it would even be possible to tuck git bases workflow on top of it?
>
> Every bug could be a branch, with each email as a commit to that
> branch. If we could git clone it locally, people could push/pull bug repports
> instead of sending mails if they prefer? 

Such issue trackers exist.  But they tend to stay at the stage of
proof-of-concept.
Relevant links include
https://tychoish.com/post/supporting-distributed-bug-tracking/ and of
course https://gitlab.com/monnier/bugit.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 11:45                       ` Theodor Thornhill
@ 2021-08-28 12:25                         ` Philip Kaludercic
  2021-08-28 13:49                         ` Dmitry Gutov
  1 sibling, 0 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-08-28 12:25 UTC (permalink / raw)
  To: Theodor Thornhill
  Cc: Eli Zaretskii, emacs-devel, Daniel Fleischer, monnier, dgutov

Theodor Thornhill <theo@thornhill.no> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Daniel Fleischer <danflscr@gmail.com> writes:
>>
>>> 1. Code exploration; view code with syntax highlighting for most file
>>> types. Being able to jump to function definitions and usages (at least
>>> in github). Many people explore code in the web before possibly cloning
>>> it locally so it's an important QOL feature.
>>
>> I think this is supported in principle, one would have to see what is
>> necessary for this to work with Elisp too.
>>
>
>
> You can absolutely read the repo, but the newish feature of github where
> some languages are backed by lsp is most likely not on the roadmap

I had to look it up, what I was referring to was this:

https://drewdevault.com/2019/07/08/Announcing-annotations-for-sourcehut.html

Yet when trying out the examples given at the end of this article, it
seems the feature isn't working/has been removed? 

> --
> Theo

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 12:09                           ` Daniel Fleischer
@ 2021-08-28 12:29                             ` Drew DeVault
  2021-08-28 13:26                             ` Jean-Christophe Helary
  1 sibling, 0 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-28 12:29 UTC (permalink / raw)
  To: Daniel Fleischer
  Cc: philipk, Theodor Thornhill, emacs-devel, monnier, Eli Zaretskii, larsi

On Sat Aug 28, 2021 at 2:09 PM CEST, Daniel Fleischer wrote:
> If you're here, a quick question about UX; starting from a project's
> main page, e.g. <https://sr.ht/~lattis/muon/>, I notice going to either
> the "source", "mailing-list" or "tickets" pages takes you to other
> subdomains where there's no way to go back using the UI. I think there
> should be a way to go back to a project's main page without using
> "back".

Aye, there should be a way. This is prioritized for the beta.

These are (most) of the tickets which are prioritized:

https://todo.sr.ht/~sircmpwn/sr.ht?search=status%3Aopen%20label%3A%22beta%22



^ permalink raw reply	[flat|nested] 525+ messages in thread

* SourceHut for Emacs (was: Gitlab Migration)
  2021-08-28  8:11       ` Eli Zaretskii
@ 2021-08-28 13:04         ` Stefan Monnier
  2021-08-30 17:59           ` Sean Whitton
  2021-08-30 20:17           ` Yuan Fu
  2021-08-28 14:07         ` Gitlab Migration Daniel Martín
  1 sibling, 2 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-28 13:04 UTC (permalink / raw)
  To: emacs-devel

Reading this discussion made me realize why I'm rooting for SourceHut:
it's the only such tool I've seen whose goals align exactly with ours.
Both philosophically (most other tools just happen to be Free Software
and but are more philosophically aligned with Open Source) and
technically (it aims for first class email support while providing as
much as possible of the shiny web features of other systems).

So at this stage, I personally don't see much point looking for other
tools.  Instead I'm just wondering how to get us to use SourceHut
(i.e. how to resolve the problems that might stand in the way, such as
getting an instance up and running on GNU machines, starting to use it
"on the side" to see in practice what issues we'll need
fixed/improved/added before we can really switch, etc...).

An obvious first issue is the one seen in Theodor's example:
https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
where the rendering of this email in the web interface completely hides
the actual patch being sent.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 12:09                           ` Daniel Fleischer
  2021-08-28 12:29                             ` Drew DeVault
@ 2021-08-28 13:26                             ` Jean-Christophe Helary
  1 sibling, 0 replies; 525+ messages in thread
From: Jean-Christophe Helary @ 2021-08-28 13:26 UTC (permalink / raw)
  To: Daniel Fleischer
  Cc: larsi, philipk, Theodor Thornhill, Emacs Devel, monnier,
	Eli Zaretskii, Drew DeVault



> On Aug 28, 2021, at 21:09, Daniel Fleischer <danflscr@gmail.com> wrote:
> 
> Hi Drew,
> 
> If you're here, a quick question about UX; starting from a project's
> main page, e.g. <https://sr.ht/~lattis/muon/>, I notice going to either
> the "source", "mailing-list" or "tickets" pages takes you to other
> subdomains where there's no way to go back using the UI. I think there
> should be a way to go back to a project's main page without using
> "back". 

There are ways to include links into the page descriptions to move around a given project's parts.
Those things are discussed on the sr.ht general list too.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 11:45                       ` Theodor Thornhill
  2021-08-28 12:25                         ` Philip Kaludercic
@ 2021-08-28 13:49                         ` Dmitry Gutov
  2021-08-28 14:11                           ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-28 13:49 UTC (permalink / raw)
  To: Theodor Thornhill, Philip Kaludercic, Daniel Fleischer
  Cc: Eli Zaretskii, monnier, emacs-devel

On 28.08.2021 14:45, Theodor Thornhill wrote:
> Philip Kaludercic<philipk@posteo.net>  writes:
> 
>> Daniel Fleischer<danflscr@gmail.com>  writes:
>>
>>> 1. Code exploration; view code with syntax highlighting for most file
>>> types. Being able to jump to function definitions and usages (at least
>>> in github). Many people explore code in the web before possibly cloning
>>> it locally so it's an important QOL feature.
>> I think this is supported in principle, one would have to see what is
>> necessary for this to work with Elisp too.
>>
> 
> You can absolutely read the repo, but the newish feature of github where
> some languages are backed by lsp is most likely not on the roadmap

It's not like Github ever supported code navigation for Emacs Lisp anyway.

This feature isn't even enabled in 
https://github.com/emacs-mirror/emacs/blob/master/src/callproc.c

Though I support navigation for C code could be made to work in a local 
installation of Gitlab.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:11       ` Eli Zaretskii
  2021-08-28 13:04         ` SourceHut for Emacs (was: Gitlab Migration) Stefan Monnier
@ 2021-08-28 14:07         ` Daniel Martín
  1 sibling, 0 replies; 525+ messages in thread
From: Daniel Martín @ 2021-08-28 14:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: danflscr, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>
> I do almost everything inside Emacs.  Once I've got bug report in
> Emacs, as part of reading email, I use the Emacs facilities to work on
> it: the code inspection features like M-. and "M-x grep", Lisp
> evaluation, Help commands, etc.  I do use the debbugs package, albeit
> rarely, mainly when I need to work on large numbers of bugs.
>
> For search, I use the Debbugs Web form (but I rarely need that,
> either); I also have email search set up, but that's also rarely
> needed.
>
> For code review, it is important for me to be able to do the following
> basic tasks efficiently while reviewing the patch:
>
>   . find code in Emacs
>   . copy code from Emacs's sources to the review text
>   . spell-check what I write and fix typos
>   . run Git commands, including forensics and patch application
>   . read past discussions of the same or related issues
>
> Does this answer your question?

Thanks, yes, that is very informative.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 13:49                         ` Dmitry Gutov
@ 2021-08-28 14:11                           ` Dmitry Gutov
  0 siblings, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-28 14:11 UTC (permalink / raw)
  To: Theodor Thornhill, Philip Kaludercic, Daniel Fleischer
  Cc: Eli Zaretskii, monnier, emacs-devel

Sorry,

On 28.08.2021 16:49, Dmitry Gutov wrote:
> Though I support navigation for C code could be made to work in a local 
            ^ suppose




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28  7:18                 ` Tassilo Horn
@ 2021-08-28 15:09                   ` Lars Ingebrigtsen
  2021-08-28 15:32                     ` Ben Mezger
  0 siblings, 1 reply; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28 15:09 UTC (permalink / raw)
  To: Tassilo Horn
  Cc: philipk, danflscr, Theodor Thornhill, emacs-devel, monnier,
	Eli Zaretskii, sir, Sean Whitton

Tassilo Horn <tsdh@gnu.org> writes:

> Also, todo.sr.ht doesn't support attachments AFAIK, i.e., reports
> accompanied with attached patches or screenshots illustrating the issue
> aren't displayed.  So that's a major bummer which would need to be
> worked on for making it suitable for emacs.

Yes, that sounds like something that needs to work before we can make
the switch.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  8:00                     ` Eli Zaretskii
@ 2021-08-28 15:20                       ` Lars Ingebrigtsen
  2021-08-28 16:04                         ` Drew DeVault
  0 siblings, 1 reply; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28 15:20 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Philip Kaludercic, danflscr, theo, emacs-devel, monnier, sir

Eli Zaretskii <eliz@gnu.org> writes:

>> It shouldn't mean anything, if GNU decides to host their own
>> instance. Otherwise, every project member would have to play to have an
>> account, but I assume mailing list contributors could continue accessing
>> the mailing list without any issue.
>
> This answers the first part, but not the second.  It looks like the
> Web-based workflows are still not supported well enough.

That's also my impression.  That is, SourceHut supports our current work
flow very well, but it doesn't really give us the popular Github/Lab
work flow: fork the repo, work on something, push it, and then do a
"pull request" towards the original repo by clicking a button, without
sending any emails to any person?

Because that's really what we want to add as an option.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 21:04                   ` Theodor Thornhill
  2021-08-28  7:55                     ` Eli Zaretskii
@ 2021-08-28 15:24                     ` Lars Ingebrigtsen
  2021-08-28 15:35                       ` Theodor Thornhill
  1 sibling, 1 reply; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28 15:24 UTC (permalink / raw)
  To: Theodor Thornhill
  Cc: philipk, danflscr, emacs-devel, monnier, Eli Zaretskii, sir

Theodor Thornhill <theo@thornhill.no> writes:

> ** Submitting patches by email.
> It is possible to send patches using a web interface.  It works by using
> the `prepare a patchset` button on your own clone.  So the process
> is usually:
>   - clone the repo
>   - pull it locally
>   - do the work
>   - push the work
>   - use the `prepare a patchset` button or `git format-patch`

Oh, the "prepare a patchset" button sounds very much like Github/Lab's
"pull request" button?  Is that accurate?

> * Code should be accompanied by documentation
> * Formatting code commits

I don't quite understand why we have these in the Gitlab requirements
list -- they seem pretty orthogonal to everything.

> * Closely integrated bugtracker
> automated tasks for patch application and status updates exist here

Is an issue automatically closed if we push a change containing a
magical string like "closes issue #foo" in the commit message?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28 15:09                   ` GitLab feature request compared with SourceHut Lars Ingebrigtsen
@ 2021-08-28 15:32                     ` Ben Mezger
  2021-08-28 15:46                       ` Lars Ingebrigtsen
  2021-08-28 18:37                       ` Tassilo Horn
  0 siblings, 2 replies; 525+ messages in thread
From: Ben Mezger @ 2021-08-28 15:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: philipk, danflscr, Theodor Thornhill, emacs-devel, monnier,
	Tassilo Horn, Eli Zaretskii, sir, Sean Whitton


> Yes, that sounds like something that needs to work before we can make
> the switch.

One point though: sr.ht payment is currently optional, but they do
have plans to start requiring payments when they reach a certain
quality -- but perhaps this is negoatible given the the nature of the
project.

https://sourcehut.org/pricing/

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> Also, todo.sr.ht doesn't support attachments AFAIK, i.e., reports
>> accompanied with attached patches or screenshots illustrating the issue
>> aren't displayed.  So that's a major bummer which would need to be
>> worked on for making it suitable for emacs.
>
> Yes, that sounds like something that needs to work before we can make
> the switch.


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

Ben Mezger

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



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 15:24                     ` Lars Ingebrigtsen
@ 2021-08-28 15:35                       ` Theodor Thornhill
  2021-08-28 15:45                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-28 15:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: Eli Zaretskii, emacs-devel, monnier, danflscr, philipk, sir



On 28 August 2021 17:24:12 CEST, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> ** Submitting patches by email.
>> It is possible to send patches using a web interface.  It works by using
>> the `prepare a patchset` button on your own clone.  So the process
>> is usually:
>>   - clone the repo
>>   - pull it locally
>>   - do the work
>>   - push the work
>>   - use the `prepare a patchset` button or `git format-patch`
>
>Oh, the "prepare a patchset" button sounds very much like Github/Lab's
>"pull request" button?  Is that accurate?
>

100%. That is what it's for. 
If you look at https://lists.sr.ht/~theo/public-inbox you'll see three posts. One is with a patch as attachment(this fails), other is git send-email and the last one is a patch of a personal fork of Emacs sent using the web UI.


>> * Code should be accompanied by documentation
>> * Formatting code commits
>
>I don't quite understand why we have these in the Gitlab requirements
>list -- they seem pretty orthogonal to everything.
>
>> * Closely integrated bugtracker
>> automated tasks for patch application and status updates exist here
>
>Is an issue automatically closed if we push a change containing a
>magical string like "closes issue #foo" in the commit message?
>
Yes



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Structured debbugs list per project
  2021-08-27  7:38             ` tomas
  2021-08-28  1:52               ` Structured debbugs list per project Arthur Miller
@ 2021-08-28 15:43               ` Michael Albinus
  2021-09-09 14:07                 ` Michael Albinus
  1 sibling, 1 reply; 525+ messages in thread
From: Michael Albinus @ 2021-08-28 15:43 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

tomas@tuxteam.de writes:

Hi Tomas,

>> > There's no reason to not have a web accessible bug mail archive
>> > indexed by bug number, for the webby folks our there. Perhaps
>> > debbugs could implement that... oh wait [1]!
>> >
>> > SCNR
>> >
>> > [1] https://debbugs.gnu.org/db/pa/lemacs.html
>>
>> Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
>> hard.
>
> Michael, you rock :)

I gave it a first shot, pushed to ELPA. The commentary has been
extended:

--8<---------------cut here---------------start------------->8---
;; If you want all bugs for a given package, sorted by severity and
;; whether already resolved, call
;;
;;   M-x debbugs-gnu-package

;; Per default it shows the bugs for package "emacs", but with a
;; prefix given to the command, different package names can be
;; specified (comma-separated).
--8<---------------cut here---------------end--------------->8---

It is not perfect, and the doc in the manual is still missing, but you
might give it a try. Pull the recent debbugs version from the GNU ELPA
repo, or wait a few hours until it appears as package in the elpa-devel
archive "https://elpa.gnu.org/devel/>.

> Cheers
>  - t

Best regards, Michael.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 15:35                       ` Theodor Thornhill
@ 2021-08-28 15:45                         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28 15:45 UTC (permalink / raw)
  To: Theodor Thornhill
  Cc: philipk, danflscr, emacs-devel, monnier, Eli Zaretskii, sir

Theodor Thornhill <theo@thornhill.no> writes:

>>Oh, the "prepare a patchset" button sounds very much like Github/Lab's
>>"pull request" button?  Is that accurate?
>
> 100%. That is what it's for. 
> If you look at https://lists.sr.ht/~theo/public-inbox you'll see three
> posts. One is with a patch as attachment(this fails), other is git
> send-email and the last one is a patch of a personal fork of Emacs
> sent using the web UI.

Cool.  Then SourceHut is a lot closer to satisfying our major
requirements than I initially thought.  

>>Is an issue automatically closed if we push a change containing a
>>magical string like "closes issue #foo" in the commit message?
>>
> Yes

Very nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28 15:32                     ` Ben Mezger
@ 2021-08-28 15:46                       ` Lars Ingebrigtsen
  2021-08-28 18:37                       ` Tassilo Horn
  1 sibling, 0 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28 15:46 UTC (permalink / raw)
  To: Ben Mezger
  Cc: philipk, danflscr, Theodor Thornhill, emacs-devel, monnier,
	Tassilo Horn, Eli Zaretskii, sir, Sean Whitton

Ben Mezger <me@benmezger.nl> writes:

> One point though: sr.ht payment is currently optional, but they do
> have plans to start requiring payments when they reach a certain
> quality -- but perhaps this is negoatible given the the nature of the
> project.
>
> https://sourcehut.org/pricing/

The GNU project would presumably host a SourceHut instance, and the GNU
project would not require payment for anything.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 15:20                       ` Lars Ingebrigtsen
@ 2021-08-28 16:04                         ` Drew DeVault
  2021-08-28 18:08                           ` Daniel Martín
  2021-08-29  1:56                           ` Dmitry Gutov
  0 siblings, 2 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-28 16:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii
  Cc: danflscr, Philip Kaludercic, theo, monnier, emacs-devel

On Sat Aug 28, 2021 at 5:20 PM CEST, Lars Ingebrigtsen wrote:
> That's also my impression. That is, SourceHut supports our current work
> flow very well, but it doesn't really give us the popular Github/Lab
> work flow: fork the repo, work on something, push it, and then do a
> "pull request" towards the original repo by clicking a button, without
> sending any emails to any person?
>
> Because that's really what we want to add as an option.

Here is a video of the sourcehut equivalent of the github/lab
pull/merge-request flow:

https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a



^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-28  7:53                   ` Tim Cross
  2021-08-28  8:52                     ` Eli Zaretskii
  2021-08-28  9:33                     ` Arthur Miller
@ 2021-08-28 16:11                     ` Drew Adams
  2021-08-29  0:54                       ` Tim Cross
  2 siblings, 1 reply; 525+ messages in thread
From: Drew Adams @ 2021-08-28 16:11 UTC (permalink / raw)
  To: Tim Cross, Arthur Miller; +Cc: Daniel Fleischer, emacs-devel

> For younger people, I suspect part of it is just a perception of email
> as being old and outdated and not fitting as well with their 'style' of
> communication, which tends to be about short messages and group chat in
> near 'real time'.

Shiny New Toy syndrome, aka Flavor Of The Month.

(Not at all limited to youth, of course.)
___


Corporate "social media": antisocial



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 16:04                         ` Drew DeVault
@ 2021-08-28 18:08                           ` Daniel Martín
  2021-08-28 18:13                             ` Eli Zaretskii
                                               ` (2 more replies)
  2021-08-29  1:56                           ` Dmitry Gutov
  1 sibling, 3 replies; 525+ messages in thread
From: Daniel Martín @ 2021-08-28 18:08 UTC (permalink / raw)
  To: Drew DeVault
  Cc: Lars Ingebrigtsen, Eli Zaretskii, danflscr, Philip Kaludercic,
	theo, monnier, emacs-devel

"Drew DeVault" <sir@cmpwn.com> writes:

>
> Here is a video of the sourcehut equivalent of the github/lab
> pull/merge-request flow:
>
> https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a

Thanks for the video.  I think the Web workflow is more or less what
people used to GitHub or Gitlab would expect.

For people that don't want to use the Web interface, the usage of git
send-mail may pose some problems.  In CONTRIBUTE there is a note that
says that patch attachments are preferred to git send-mail for some
reasons:

- It delivers patches in the correct and easily-recognizable format, and
  in a more reliable way. (I'm not sure what this means.)

- Makes the job of applying the patches easier and less error-prone.
  (Perhaps this just requires learning a new way to work?).

- Allows sending patches whose author is someone other than the email
  sender. (I think this is already supported: git config --global
  user.email would set the author's email, and git config --global
  sendemail.from, or passing the --from=<address> option to git
  send-mail, would set the sender's email address.)

But even if patch attachments are not supported by sourcehut, I think
support for image attachments is at least required for some issues.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 18:08                           ` Daniel Martín
@ 2021-08-28 18:13                             ` Eli Zaretskii
  2021-08-28 18:19                             ` Lars Ingebrigtsen
  2021-08-28 18:32                             ` Drew DeVault
  2 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-28 18:13 UTC (permalink / raw)
  To: Daniel Martín
  Cc: philipk, danflscr, theo, emacs-devel, monnier, larsi, sir

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>,  "Eli Zaretskii" <eliz@gnu.org>,
>   danflscr@gmail.com,  Philip Kaludercic <philipk@posteo.net>,
>   theo@thornhill.no,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 20:08:37 +0200
> 
> - It delivers patches in the correct and easily-recognizable format, and
>   in a more reliable way. (I'm not sure what this means.)

Think MUAs that wrap long lines and otherwise do tricks with
whitespace.

> - Allows sending patches whose author is someone other than the email
>   sender. (I think this is already supported: git config --global
>   user.email would set the author's email, and git config --global
>   sendemail.from, or passing the --from=<address> option to git
>   send-mail, would set the sender's email address.)

That won't help with "git format-patch" whose results are sent.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 18:08                           ` Daniel Martín
  2021-08-28 18:13                             ` Eli Zaretskii
@ 2021-08-28 18:19                             ` Lars Ingebrigtsen
  2021-08-28 18:32                             ` Drew DeVault
  2 siblings, 0 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-28 18:19 UTC (permalink / raw)
  To: Daniel Martín
  Cc: Philip Kaludercic, danflscr, theo, emacs-devel, monnier,
	Eli Zaretskii, Drew DeVault

Daniel Martín <mardani29@yahoo.es> writes:

> For people that don't want to use the Web interface, the usage of git
> send-mail may pose some problems.  In CONTRIBUTE there is a note that
> says that patch attachments are preferred to git send-mail for some
> reasons:

Well, we really don't care as long as the patches reach us unscathed.

In my experience, it's more likely that a patch won't be mangled if it's
in an attachment (which is why CONTRIBUTE says that), but if you have a
setup that allows you to send patches safely otherwise (i.e., you're not
using Gmail :-)), then we don't care.

> But even if patch attachments are not supported by sourcehut, I think
> support for image attachments is at least required for some issues.

Yeah, it has to support attachments.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 18:08                           ` Daniel Martín
  2021-08-28 18:13                             ` Eli Zaretskii
  2021-08-28 18:19                             ` Lars Ingebrigtsen
@ 2021-08-28 18:32                             ` Drew DeVault
  2 siblings, 0 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-28 18:32 UTC (permalink / raw)
  To: Daniel Martín
  Cc: Philip Kaludercic, danflscr, theo, emacs-devel, monnier,
	Lars Ingebrigtsen, Eli Zaretskii

On Sat Aug 28, 2021 at 8:08 PM CEST, Daniel Martín wrote:
> - It delivers patches in the correct and easily-recognizable format, and
> in a more reliable way. (I'm not sure what this means.)

Reliability is the main reason for suggesting git send-email :) It does
it for you, and does it correctly.

> - Makes the job of applying the patches easier and less error-prone.
> (Perhaps this just requires learning a new way to work?).

Depends, I suppose.

> - Allows sending patches whose author is someone other than the email
> sender. (I think this is already supported: git config --global
> user.email would set the author's email, and git config --global
> sendemail.from, or passing the --from=<address> option to git
> send-mail, would set the sender's email address.)

This just werks by default with git send-email, it automatically adds
the author.

> But even if patch attachments are not supported by sourcehut, I think
> support for image attachments is at least required for some issues.

Yeah, we can expand the attachments support for sure.

Generally I understand the desire for some projects to have patch
attachments as their workflow, but I find that every user who is
instructed on git send-email (perhaps by [0]) finds it much better.

[0] https://git-send-email.io



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28 15:32                     ` Ben Mezger
  2021-08-28 15:46                       ` Lars Ingebrigtsen
@ 2021-08-28 18:37                       ` Tassilo Horn
  2021-08-28 20:15                         ` Ben Mezger
  1 sibling, 1 reply; 525+ messages in thread
From: Tassilo Horn @ 2021-08-28 18:37 UTC (permalink / raw)
  To: Ben Mezger
  Cc: philipk, danflscr, Theodor Thornhill, sir, monnier,
	Lars Ingebrigtsen, emacs-devel, Eli Zaretskii, Sean Whitton

Ben Mezger <me@benmezger.nl> writes:

>> Yes, that sounds like something that needs to work before we can make
>> the switch.
>
> One point though: sr.ht payment is currently optional, but they do
> have plans to start requiring payments when they reach a certain
> quality

I think you already must be a paying user to use the CI service as a
result of abuse of the infrastructure for cryptocurrency mining.

> -- but perhaps this is negoatible given the the nature of the project.

As Lars already said, that's irrelevant for us because we'd host
sourcehut the software on GNU infrastructure anyway.

However, I want to point out that I'm very happily paying those 20 bucks
a year to help making sr.ht a sustainable service.  It's so much better
to pay with your money rather than your data.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28 18:37                       ` Tassilo Horn
@ 2021-08-28 20:15                         ` Ben Mezger
  2021-08-28 22:20                           ` Jean-Christophe Helary
  2021-08-29  3:03                           ` Richard Stallman
  0 siblings, 2 replies; 525+ messages in thread
From: Ben Mezger @ 2021-08-28 20:15 UTC (permalink / raw)
  To: Tassilo Horn
  Cc: philipk, danflscr, Theodor Thornhill, sir, monnier,
	Lars Ingebrigtsen, emacs-devel, Eli Zaretskii, Sean Whitton


> As Lars already said, that's irrelevant for us because we'd host
> sourcehut the software on GNU infrastructure anyway.

I was not aware about the possibility of hosting sourcehut at all -- but
this does seem like a plausible solution indeed.

> However, I want to point out that I'm very happily paying those 20 bucks
> a year to help making sr.ht a sustainable service.  It's so much better
> to pay with your money rather than your data.

Definitely, folks at sourcehut have been doing a great job at tacking
this sort of issue -- in fact, afaik, they are the only ones actually
trying to solve this mailing list problem. I am unaware of any other
solution that tackles code contribution the way they do it.

Maybe if Emacs makes the first move, perhaps other projects may follow
the same path.

Tassilo Horn <tsdh@gnu.org> writes:

> Ben Mezger <me@benmezger.nl> writes:
>
>>> Yes, that sounds like something that needs to work before we can make
>>> the switch.
>>
>> One point though: sr.ht payment is currently optional, but they do
>> have plans to start requiring payments when they reach a certain
>> quality
>
> I think you already must be a paying user to use the CI service as a
> result of abuse of the infrastructure for cryptocurrency mining.
>
>> -- but perhaps this is negoatible given the the nature of the project.
>
> As Lars already said, that's irrelevant for us because we'd host
> sourcehut the software on GNU infrastructure anyway.
>
> However, I want to point out that I'm very happily paying those 20 bucks
> a year to help making sr.ht a sustainable service.  It's so much better
> to pay with your money rather than your data.
>
> Bye,
> Tassilo


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

Ben Mezger

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



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  9:25       ` Alan Third
  2021-08-28  9:40         ` Eli Zaretskii
@ 2021-08-28 21:42         ` Basil L. Contovounesios
  2021-08-28 22:03           ` Alan Third
  1 sibling, 1 reply; 525+ messages in thread
From: Basil L. Contovounesios @ 2021-08-28 21:42 UTC (permalink / raw)
  To: Alan Third
  Cc: Eli Zaretskii, Stefan Monnier, emacs-devel, danflscr, mardani29

Alan Third [2021-08-28 10:25 +0100] wrote:

> I occasionally use the usertags feature to tag bug reports as for NS,
> which is very helpful for finding relevant bugs. Someone else was
> doing it before me, and not all NS bugs are tagged. I struggle to
> remember how to use the email-based admin for debbugs, so I only ever
> tag them when I'm using the emacs debbugs UI, which is much less often
> than I use my MUA.
>
> Not relevant to this discussion, but it has just occurred to me that
> since I write all my emails in Emacs it should be possible to create
> some sort of system for semi-automatically inserting debbugs commands
> into the current email body.

You mean like 'M-x debbugs-gnu-make-control-message', or something more
powerful than that?

-- 
Basil



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 21:42         ` Basil L. Contovounesios
@ 2021-08-28 22:03           ` Alan Third
  0 siblings, 0 replies; 525+ messages in thread
From: Alan Third @ 2021-08-28 22:03 UTC (permalink / raw)
  To: Basil L. Contovounesios
  Cc: Eli Zaretskii, mardani29, danflscr, Stefan Monnier, emacs-devel

On Sat, Aug 28, 2021 at 10:42:10PM +0100, Basil L. Contovounesios wrote:
> Alan Third [2021-08-28 10:25 +0100] wrote:
> 
> > I occasionally use the usertags feature to tag bug reports as for NS,
> > which is very helpful for finding relevant bugs. Someone else was
> > doing it before me, and not all NS bugs are tagged. I struggle to
> > remember how to use the email-based admin for debbugs, so I only ever
> > tag them when I'm using the emacs debbugs UI, which is much less often
> > than I use my MUA.
> >
> > Not relevant to this discussion, but it has just occurred to me that
> > since I write all my emails in Emacs it should be possible to create
> > some sort of system for semi-automatically inserting debbugs commands
> > into the current email body.
> 
> You mean like 'M-x debbugs-gnu-make-control-message', or something more
> powerful than that?

I only just learnt you can use that in an existing email, but I use
post-mode with mutt, so I don't think it will work for me. At the very
least it'll put me in message mode, which isn't really what I want.
-- 
Alan Third



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28 20:15                         ` Ben Mezger
@ 2021-08-28 22:20                           ` Jean-Christophe Helary
  2021-08-29  3:03                           ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: Jean-Christophe Helary @ 2021-08-28 22:20 UTC (permalink / raw)
  To: Ben Mezger
  Cc: philipk, Daniel Fleischer, Theodor Thornhill, Emacs Devel,
	Eli Zaretskii, Stefan Monnier, Tassilo Horn, Lars Ingebrigtsen,
	Drew DeVault, Sean Whitton



> On Aug 29, 2021, at 5:15, Ben Mezger <me@benmezger.nl> wrote:
> 
> 
>> As Lars already said, that's irrelevant for us because we'd host
>> sourcehut the software on GNU infrastructure anyway.
> 
> I was not aware about the possibility of hosting sourcehut at all -- but
> this does seem like a plausible solution indeed.

sourcehut is free software.

https://man.sr.ht/installation.md

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-28 16:11                     ` [External] : " Drew Adams
@ 2021-08-29  0:54                       ` Tim Cross
  2021-08-29  3:18                         ` Drew Adams
  0 siblings, 1 reply; 525+ messages in thread
From: Tim Cross @ 2021-08-29  0:54 UTC (permalink / raw)
  To: Drew Adams; +Cc: Daniel Fleischer, Arthur Miller, emacs-devel


Drew Adams <drew.adams@oracle.com> writes:

>> For younger people, I suspect part of it is just a perception of email
>> as being old and outdated and not fitting as well with their 'style' of
>> communication, which tends to be about short messages and group chat in
>> near 'real time'.
>
> Shiny New Toy syndrome, aka Flavor Of The Month.
>
> (Not at all limited to youth, of course.)

Sadly, I think comments like this are all too frequent from us oldies.
They feel simplistic, overly dismissive and somewhat arrogant. For youth,
nearly everything is shiny and new - we forget that for us, email was
shiny and new once upon a time. The difference could just as easily be
due to us 'old dogs' failing to learn new tricks and failing to
recognise the evolution in social interaction brought about by new
technologies. If it is just the flavour of the month, it is a very long
month and I see little evidence of that flavour becoming stale. I'm sure
it will continue to evolve, but feel it is very unlikely to go back the
other way. 



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 11:33           ` Dmitry Gutov
  2021-08-28  5:05             ` Arthur Miller
@ 2021-08-29  1:27             ` Po Lu
  1 sibling, 0 replies; 525+ messages in thread
From: Po Lu @ 2021-08-29  1:27 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Arthur Miller, Lars Ingebrigtsen, Philip Kaludercic,
	Daniel Fleischer, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> Yes, you're both talking about git hooks. A minor disadvantage is that
> a hook needs to be installed, and then a bug in a hook implementation
> can stop you from being able to make a commit (there are overrides,
> but those require more googling).

It is certainly a very minor disadvantage, as it's always been accurate
for me.

> CI is good because if its visibility: the list of checks on current
> PRs is visible to every newcomer, instead of being buried somewhere
> near the end of the CONTRIBUTE document.

But shouldn't contributors be expected to read CONTRIBUTE anyhow?  If
someone does not read the CONTRIBUTE file, he will not know to add
entries to NEWS, to write correctly formatted commit messages, and so
on.  A list of checks done on formatting does not seem as important as
some of the other topics covered "somewhere near the end of the
CONTRIBUTE document."




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28 16:04                         ` Drew DeVault
  2021-08-28 18:08                           ` Daniel Martín
@ 2021-08-29  1:56                           ` Dmitry Gutov
  2021-08-29  6:55                             ` Drew DeVault
  2021-08-29  7:42                             ` Lars Ingebrigtsen
  1 sibling, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-29  1:56 UTC (permalink / raw)
  To: Drew DeVault, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On 28.08.2021 19:04, Drew DeVault wrote:
> On Sat Aug 28, 2021 at 5:20 PM CEST, Lars Ingebrigtsen wrote:
>> That's also my impression. That is, SourceHut supports our current work
>> flow very well, but it doesn't really give us the popular Github/Lab
>> work flow: fork the repo, work on something, push it, and then do a
>> "pull request" towards the original repo by clicking a button, without
>> sending any emails to any person?
>>
>> Because that's really what we want to add as an option.
> Here is a video of the sourcehut equivalent of the github/lab
> pull/merge-request flow:
> 
> https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a

Thanks for the video. AFAICT it shows a workflow that follows what the 
Linux kernel and associated projects do, so it's clearly workable.

But compared to "the Git**b workflow", here are a few 
frictions/downsides that came to mind:

- You need to input a correct email to send a patchset to. First, it's a 
step where the contributor would have to stop and look stuff up (which 
email indeed to use?), and then they might end up sending the whole 
thing to one of the contributors directly. Whereas, with rare 
exceptions, we probably want to have a section on our "sourcehut project 
page" which lists all current and past submissions.

This seems not too hard to fix, at least conceptually.

- Every version of a patchset is re-submitted as a whole. I suppose 
there is some purity in that, but if for example the original submission 
is big, and I only asked the author to change a few relatively minor 
things, I prefer they do that in a separate commit. Then, in a git**b 
workflow, I see that the branch was updated with that one commit, and I 
don't have to scan the other commit(s) for any unrelated/breaking 
changes. This kind of back-and-forth can go for several rounds (minor 
change here, minor change there). If the user has to rebase and resend 
their whole branch every time, and if the branch has multiple commits, 
that's a lot of extra traffic. Of course, some users want to rebase 
anyway (and I rarely bother asking them to stop), so it only really 
applies to some submissions. But I'd generally prefer to see some fixup 
commits (during the review rounds), and then a rebase at the end of the 
review. Or just merge the whole branch, with fixes and all (this too can 
make sense, depending on the nature of the requested changes). This 
seems to require less work from everybody involved.

- Rebasing. Some of our valued contributors are not 100% comfortable 
with the more advanced features of Git, rebasing included. Our general 
recommendation until now has been to prefer merge commits. If the 
general workflow is going to require people to 'git rebase -i' on a 
regular basis, it could be a problem.

Bonus questions:

- Can we have discussion subthreads "attached" to particular pieces of 
the submitted patches? Like, a line, or a hunk. Being able to view those 
in a compact fashion, right in the middle of the context, is pretty handy.

- Can I jump in in the middle of a patch discussion with a question or 
an advice and have all subsequent messages in that discussion sent to me 
too, if I'm not subscribed to the target mailing list? Does that depend 
on all participants putting me in Cc?

- Can I do that "jumping in" from the web interface?

- Can I "unsubscribe" from replies to a topic/thread/patchset I'm not 
longer interested in?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:00           ` Eli Zaretskii
@ 2021-08-29  2:27             ` Dmitry Gutov
  2021-08-30  2:58               ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-29  2:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, danflscr, monnier, emacs-devel

On 28.08.2021 09:00, Eli Zaretskii wrote:
>> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 28 Aug 2021 00:09:41 +0300
>>
>>   From what I have seen of it, it's email-first, and far from "full and
>> convenient support for ... web".
>>
>> For example, those quality-of-life features that Gitlab has in the
>> browser which I previously figured would be difficult to translate  to
>> email (the code review workflow, with inline comments and updates from
>> the branch; automatically updated CI indicators and links to builds;
>> editing of messages) are predictably absent.
> 
> That sounds worrisome.
> 
> Can you tell how did you see what SourceHut offers in this department,
> so others (myself included) could have a look?  I cannot find any
> documentation of the features.

I used my web browser, mostly following the links others submitted in 
this discussion (and then followed some links from there), also did some 
educated guessing (and turned out to be wrong on the subject of CI 
indicators and links to builds).

The video Drew posted yesterday (see the response to it I sent just now) 
has also been illuminating.

I haven't looked too deeply or tried to work with it personally, so my 
impressions are of course superficial and biased. Perhaps somebody wants 
to create a test project on sr.ht and invite a bunch of us to 
collaborate? Or set up a private installation like emba.gnu.org, with 
the same end goal.

>> Of course, it should still be a significant step forward compared to the
>> current situation.
> 
> Can you elaborate why you think so, given the lack of the above
> features?

It seems to provide a nicer/better bug tracker and mailing list archive 
viewers than the ones we already have. With unified views, better 
searching, tagging and perhaps even an ability to write messages from 
the browser (which is certain to appeal to some newcomers). Maybe also 
features like subscribe/unsubscribe to a discussion, though that looks 
less certain.

We have generally routed around those problems (by doing extra manual 
work, usually; or asking others to do it), but that haven't made them go 
away. E.g. recall at the beginning of this thread you suggested the 
author would do a search for the previous thread on the subject and then 
find the gitlab issue there. I'm guessing it was, at least in part, due 
to the search on lists.gnu.org being not that great.

Of course, whether this promise will hold up (with good performance and 
few bugs) remain to be seen, but Drew has a good track record.

Overall, if we finally accept that neither UI familiarity (for new 
users) nor workflow familiarity (for new contributors) are a priority 
for the Emacs project, this might a reasonable option to migrate to. I 
just wonder whether we'd have to do another migration in 5-10 years, 
with the natural change in Emacs contributor base.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  2:15           ` Lars Ingebrigtsen
@ 2021-08-29  3:00             ` Richard Stallman
  2021-08-29 18:40               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: philipk, danflscr, emacs-devel, joaotavora, arthur.miller, eliz

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

  > We haven't found such a system yet.  sr.ht is perhaps an option, but my
  > first impression is that it's too different from GitHub/Lab, really.

Why should such a difference disqualify it?  We have no commitment to
GitHub/Lab; on the contrary, we disapprove of them.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27 18:19       ` João Távora
  2021-08-28  2:07         ` Arthur Miller
@ 2021-08-29  3:01         ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:01 UTC (permalink / raw)
  To: João Távora; +Cc: eliz, danflscr, philipk, emacs-devel

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

  > The main question is where the discussion happens: it has to be email,
  > period.

It has to be email, because email can be read and written off-line.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-27 17:08                 ` tomas
@ 2021-08-29  3:01                   ` Richard Stallman
  0 siblings, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:01 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

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

I publish a page about nasty things about Slack, but I only cover
those which are nasty in moral terms.  Those which are merely
painfully annoying, are out of scope.

However, do you think that if the Slack client were free
it would be possible to correct the painfully annoying behavior?
If so, that relates the problem to the injustice of the nonfree client
and I could include it.

But I would need a reference -- a page that describes the behavior and
why it is annoying.  Can you find one?  Or make one?



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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  4:50       ` Arthur Miller
@ 2021-08-29  3:03         ` Richard Stallman
  0 siblings, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:03 UTC (permalink / raw)
  To: Arthur Miller; +Cc: theophilusx, emacs-devel

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

  > > To recommend that people use one of them would contradict our goal of
  > > computing that respects the user's freedom.  Thus, we can't recommend
  > > any of them.  Whatever practical "advantages" it might have, they
  > > could not make up for the moral contradiction it would cause.

  > ? I didn't recommend to anyone to use those, nor did I spoke in their favor, I
  > just generally spoke about what some people prefer and I try to speculate why.

I am glad to know you're not arguing for them, and that I
misunderstood before.

That misunderstanding was not just random.  In a discussion about what
methods we should adopt, to say that a large group of people (whom we
would like to recruit) are accustomed to methods A, B and C is not a
big step away from advocating their use.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:58     ` Eli Zaretskii
@ 2021-08-29  3:03       ` Richard Stallman
  0 siblings, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, danflscr, emacs-devel

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

  > > This is why the GNU Project continues to specify that a GNU package
  > > should have a published bug-reporting email address.

  > Not to be a whistle-blower, but if that's a rule, then some GNU
  > packages deviate from it.

Its unfortunate.  I wonder if I would be able to report a bug
in those ways.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-28  6:57                 ` tomas
  2021-08-28  7:41                   ` Eli Zaretskii
@ 2021-08-29  3:03                   ` Richard Stallman
  2021-08-29 12:55                     ` Eli Zaretskii
  1 sibling, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:03 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

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

  > On top of that, some MUAs (again, the same) don't know what a
  > Message-ID is and thread based on Subject. Resulting in monster
  > threads with the incredibly informative Subject "Re:".

Would someone like to implement Message-ID threading in Rmail?
I would definitely appreciate it.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-28 20:15                         ` Ben Mezger
  2021-08-28 22:20                           ` Jean-Christophe Helary
@ 2021-08-29  3:03                           ` Richard Stallman
  2021-08-29  7:10                             ` Drew DeVault
  1 sibling, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-29  3:03 UTC (permalink / raw)
  To: Ben Mezger
  Cc: philipk, danflscr, theo, emacs-devel, eliz, monnier, tsdh, larsi,
	sir, spwhitton

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

  > Definitely, folks at sourcehut have been doing a great job at tacking
  > this sort of issue -- in fact, afaik, they are the only ones actually
  > trying to solve this mailing list problem. I am unaware of any other
  > solution that tackles code contribution the way they do it.

  > Maybe if Emacs makes the first move, perhaps other projects may follow
  > the same path.

Sorry -- what is "first move" that is being proposed?

We want to host Emacs on a GNU server, not someone else's.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-29  0:54                       ` Tim Cross
@ 2021-08-29  3:18                         ` Drew Adams
  2021-08-30  2:59                           ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Drew Adams @ 2021-08-29  3:18 UTC (permalink / raw)
  To: Tim Cross; +Cc: Daniel Fleischer, Arthur Miller, emacs-devel

> >> For younger people, I suspect part of it is just a perception of email
> >> as being old and outdated and not fitting as well with their 'style' of
> >> communication, which tends to be about short messages and group chat in
> >> near 'real time'.
> >
> > Shiny New Toy syndrome, aka Flavor Of The Month.
> > (Not at all limited to youth, of course.)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Sadly, I think comments like this are all too
> frequent from us oldies.

"Comments like these" is facile dismissal.

> They feel simplistic, overly dismissive and
> somewhat arrogant. 

That's exactly what that comment you just made
feels like.  Your complaint does what it
complains about.

> For youth, nearly everything is shiny and new
> - we forget that for us, email was shiny and
> new once upon a time.

I don't forget it.  It's you who laid this on
"younger people", not I.  Your description.

> The difference could just as easily be due
> to us 'old dogs' failing to learn new tricks
> and failing to recognise the evolution in social
> interaction brought about by new technologies.

I don't see it as old vs new dogs.  There are
plenty of old dogs who new-trick all the time.

Shiny New Toy syndrome doesn't respect age.
The toys might differ on average for different
age groups, but that's about all.

> If it is just the flavour of the month, it is
> a very long month and I see little evidence of
> that flavour becoming stale. I'm sure it will
> continue to evolve, but feel it is very unlikely
> to go back the other way.

Define "back the other way".  What dichotomy
are you hinting at: email versus ____?

What's the flavor you're talking about?
Everything other than email?  Or a particular
thing, such as Slack?  Wait and see how long
any particular remains in the Top 10.

There's not really anything new about "short
messages and group chat" versus long messages
and one-on-one.  What's new (and ever-changing)
are the possible forms.

Or if you mean social media powerhouses such
as Facebook then sure, there's no Facebook of
the month.  Yesterday's shiny new Instagram is
just Facebook.  It'll likely be a while before
Facebook and Google go the way of old IBM.
___

There's a difference between (1) being attracted
to something new and (2) being distracted toward
whatever pops into the field of view and away
from what was noticed a millisecond ago.  #2 is
what Shiny New Toy Syndrome is about.

And no, as I said, the malady is _not at all_
limited to youth.  Its underlying, unseen
foundation is _commercial_.  We (of all ages)
succumb to it in part because what appears on
the shelves changes.
___

Anyway, this is fairly off-topic now.

Your point was about youth's perception of email
as "old".  My point was that a view of things as
"old" can be a sign of Shiny New Toy syndrome -
a relentless, overwhelming appetite for "new".

That's not youth; it's market society.

(And no, not everyone is infected to the same
degree.)



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  1:56                           ` Dmitry Gutov
@ 2021-08-29  6:55                             ` Drew DeVault
  2021-08-29  7:38                               ` Eli Zaretskii
  2021-08-29 23:17                               ` Dmitry Gutov
  2021-08-29  7:42                             ` Lars Ingebrigtsen
  1 sibling, 2 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-29  6:55 UTC (permalink / raw)
  To: Dmitry Gutov, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On Sun Aug 29, 2021 at 3:56 AM CEST, Dmitry Gutov wrote:
> - You need to input a correct email to send a patchset to.
> This seems not too hard to fix, at least conceptually.

Aye. A future enhancement will pre-fill this with the appropriate email
address for the project's mailing list.

> - Every version of a patchset is re-submitted as a whole. I suppose
> there is some purity in that, but if for example the original submission
> is big, and I only asked the author to change a few relatively minor
> things, I prefer they do that in a separate commit. Then, in a git**b
> workflow, I see that the branch was updated with that one commit, and I
> don't have to scan the other commit(s) for any unrelated/breaking
> changes.

This is a bad practice for git, because it makes the history worse. This
has consequences, for example, with tools like git bisect. Instead, git
range-diff is helpful for comparing the previous and new version of a
patch, and future improvements to the web UI will incorporate it to
allow you to easily diff between patchset revisions. The idea is
something similar to Gerrit's approach, you may be familiar with that.

> - Rebasing. Some of our valued contributors are not 100% comfortable
> with the more advanced features of Git, rebasing included. Our general
> recommendation until now has been to prefer merge commits. If the
> general workflow is going to require people to 'git rebase -i' on a
> regular basis, it could be a problem.

We wrote another tutorial about git rebase which has been very helpful:

https://git-rebase.io

In general we are a hard "no" on shying away from powerful tools because
they are intimidating to new users. We prefer to cultivate a culture of
mentorship instead.

> - Can we have discussion subthreads "attached" to particular pieces of
> the submitted patches? Like, a line, or a hunk. Being able to view those
> in a compact fashion, right in the middle of the context, is pretty
> handy.

Yes, though it's based on heuristics and we're still working on it.
Here's a simple example:

https://lists.sr.ht/~mpu/qbe/patches/24383

> - Can I jump in in the middle of a patch discussion with a question or
> an advice and have all subsequent messages in that discussion sent to me
> too, if I'm not subscribed to the target mailing list? Does that depend
> on all participants putting me in Cc?

It depends on all of the participants Cc'ing you. It is common practice
to "reply all" on mailing lists for this reason.

> - Can I do that "jumping in" from the web interface?

No, but this is a prioritized issue.

> - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
> longer interested in?

In a sense. Because you don't have to subscribe to the mailing list to
participate in a thread, you won't get emails unless the sender has Cc'd
you. But you cannot stop them from Cc'ing you, and neither can we,
unless you ask nicely - which is not a software solution. Such emails
are not relayed by our mail servers, so it's out of our control.

Subscribing to individual threads is also prioritized.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-29  3:03                           ` Richard Stallman
@ 2021-08-29  7:10                             ` Drew DeVault
  2021-08-29 18:30                               ` Ben Mezger
  0 siblings, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-29  7:10 UTC (permalink / raw)
  To: rms, Ben Mezger
  Cc: philipk, danflscr, theo, emacs-devel, monnier, tsdh, larsi, eliz,
	spwhitton

On Sun Aug 29, 2021 at 5:03 AM CEST, Richard Stallman wrote:
> > Maybe if Emacs makes the first move, perhaps other projects may follow
> > the same path.
>
> Sorry -- what is "first move" that is being proposed?
>
> We want to host Emacs on a GNU server, not someone else's.

You can run the sourcehut software on GNU servers, it is 100% free
software, mostly AGPL. I would encourage you to do so.

However, I think that this is a rare case where you could also use our
servers if you so desired. The software on our servers is not patched,
it's the same free software you would run on yours. If you did some
reading on sourcehut, I think you would find our philosophy quite
compatible with GNU's ideals. It would be nice to have the emacs vote of
confidence in our services, in the strategic sense of mutual support
between organizations which believe in free software.

SourceHut is a straight upgrade from the existing mailing lists, and
supports the existing workflow almost 1:1, perhaps pending some minor
enhancements around attachments. The web tools to accomodate the
pull-request generation are at a prototype stage, but will be improved.
The free software ethic is here to stay.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  6:55                             ` Drew DeVault
@ 2021-08-29  7:38                               ` Eli Zaretskii
  2021-08-29  7:42                                 ` Drew DeVault
  2021-08-29 23:17                               ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29  7:38 UTC (permalink / raw)
  To: Drew DeVault; +Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi

> Date: Sun, 29 Aug 2021 08:55:41 +0200
> Cc: <danflscr@gmail.com>, "Philip Kaludercic" <philipk@posteo.net>,
>  <theo@thornhill.no>, <monnier@iro.umontreal.ca>, <emacs-devel@gnu.org>
> From: "Drew DeVault" <sir@cmpwn.com>
> 
> > - Rebasing. Some of our valued contributors are not 100% comfortable
> > with the more advanced features of Git, rebasing included. Our general
> > recommendation until now has been to prefer merge commits. If the
> > general workflow is going to require people to 'git rebase -i' on a
> > regular basis, it could be a problem.
> 
> We wrote another tutorial about git rebase which has been very helpful:
> 
> https://git-rebase.io
> 
> In general we are a hard "no" on shying away from powerful tools because
> they are intimidating to new users. We prefer to cultivate a culture of
> mentorship instead.

Rebasing is not just intimidating, it has real problems as well.  One
problem that particularly bothers us is that it could, in some
circumstances, cause the same commit to be present more than once.

I find a hard requirement to use rebase to be user-unfriendly, because
some of us simply don't want to rebase, for reasons of preserving the
original history of the development.  Is rebasing really a requirement
in SourceHut?

> > - Can I jump in in the middle of a patch discussion with a question or
> > an advice and have all subsequent messages in that discussion sent to me
> > too, if I'm not subscribed to the target mailing list? Does that depend
> > on all participants putting me in Cc?
> 
> It depends on all of the participants Cc'ing you. It is common practice
> to "reply all" on mailing lists for this reason.

Too many people forget to "Reply All", we have this all the time on
our current bug tracker.  Is there a way to arrange for automatic
subscription to a discussion once you post to that discussion?

> > - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
> > longer interested in?
> 
> In a sense. Because you don't have to subscribe to the mailing list to
> participate in a thread, you won't get emails unless the sender has Cc'd
> you. But you cannot stop them from Cc'ing you, and neither can we,
> unless you ask nicely - which is not a software solution. Such emails
> are not relayed by our mail servers, so it's out of our control.
> 
> Subscribing to individual threads is also prioritized.

Does this mean that currently starting a discussion doesn't
automatically subscribe me to that discussion?

Thanks.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  7:38                               ` Eli Zaretskii
@ 2021-08-29  7:42                                 ` Drew DeVault
  2021-08-29  8:21                                   ` Eli Zaretskii
  2021-08-29 22:27                                   ` Dmitry Gutov
  0 siblings, 2 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-29  7:42 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi

On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
> Rebasing is not just intimidating, it has real problems as well. One
> problem that particularly bothers us is that it could, in some
> circumstances, cause the same commit to be present more than once.
>
> I find a hard requirement to use rebase to be user-unfriendly, because
> some of us simply don't want to rebase, for reasons of preserving the
> original history of the development. Is rebasing really a requirement
> in SourceHut?

No, it's not a requirement. It's just something I think is a good idea.

How do you end up with the same commit twice?

> > It depends on all of the participants Cc'ing you. It is common practice
> > to "reply all" on mailing lists for this reason.
>
> Too many people forget to "Reply All", we have this all the time on
> our current bug tracker. Is there a way to arrange for automatic
> subscription to a discussion once you post to that discussion?

This is probably something which can be done. Can you file a ticket?
Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
subject line and the body as markdown.

> > In a sense. Because you don't have to subscribe to the mailing list to
> > participate in a thread, you won't get emails unless the sender has Cc'd
> > you. But you cannot stop them from Cc'ing you, and neither can we,
> > unless you ask nicely - which is not a software solution. Such emails
> > are not relayed by our mail servers, so it's out of our control.
> > 
> > Subscribing to individual threads is also prioritized.
>
> Does this mean that currently starting a discussion doesn't
> automatically subscribe me to that discussion?

Yep. See previous answer.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  1:56                           ` Dmitry Gutov
  2021-08-29  6:55                             ` Drew DeVault
@ 2021-08-29  7:42                             ` Lars Ingebrigtsen
  2021-08-29  8:22                               ` Eli Zaretskii
  2021-08-29 21:13                               ` Dmitry Gutov
  1 sibling, 2 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-29  7:42 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Philip Kaludercic, danflscr, theo, emacs-devel, monnier,
	Eli Zaretskii, Drew DeVault

Dmitry Gutov <dgutov@yandex.ru> writes:

> - Rebasing. Some of our valued contributors are not 100% comfortable
>   with the more advanced features of Git, rebasing included. Our
>   general recommendation until now has been to prefer merge
>   commits.

Well, one of the co-maintainers is sceptical towards rebasing, and the
other one uses it exclusively, so I don't think we currently have any
recommendation on the matter.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  7:42                                 ` Drew DeVault
@ 2021-08-29  8:21                                   ` Eli Zaretskii
  2021-08-29  8:23                                     ` Drew DeVault
                                                       ` (2 more replies)
  2021-08-29 22:27                                   ` Dmitry Gutov
  1 sibling, 3 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29  8:21 UTC (permalink / raw)
  To: Drew DeVault; +Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi

> Date: Sun, 29 Aug 2021 09:42:14 +0200
> From: "Drew DeVault" <sir@cmpwn.com>
> Cc: <dgutov@yandex.ru>, <larsi@gnus.org>, <danflscr@gmail.com>,
>  <philipk@posteo.net>, <theo@thornhill.no>, <monnier@iro.umontreal.ca>,
>  <emacs-devel@gnu.org>
> 
> On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
> > Rebasing is not just intimidating, it has real problems as well. One
> > problem that particularly bothers us is that it could, in some
> > circumstances, cause the same commit to be present more than once.
> >
> > I find a hard requirement to use rebase to be user-unfriendly, because
> > some of us simply don't want to rebase, for reasons of preserving the
> > original history of the development. Is rebasing really a requirement
> > in SourceHut?
> 
> No, it's not a requirement. It's just something I think is a good idea.

OK, thanks.  Then I don't think we have a problem here.

> How do you end up with the same commit twice?

I no longer remember the exact details, it was something we bumped
into during discussions when Emacs switched to Git.  AFAIR, it had to
do with working on a feature branch and frequently rebasing it onto
the latest master (so that the feature branch doesn't diverge too
much), then later merging from the feature branch to master.

> > > It depends on all of the participants Cc'ing you. It is common practice
> > > to "reply all" on mailing lists for this reason.
> >
> > Too many people forget to "Reply All", we have this all the time on
> > our current bug tracker. Is there a way to arrange for automatic
> > subscription to a discussion once you post to that discussion?
> 
> This is probably something which can be done. Can you file a ticket?
> Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
> subject line and the body as markdown.

Will do.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  7:42                             ` Lars Ingebrigtsen
@ 2021-08-29  8:22                               ` Eli Zaretskii
  2021-08-29 21:13                               ` Dmitry Gutov
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29  8:22 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, sir

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 29 Aug 2021 09:42:18 +0200
> Cc: Philip Kaludercic <philipk@posteo.net>, danflscr@gmail.com,
>  theo@thornhill.no, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  Eli Zaretskii <eliz@gnu.org>, Drew DeVault <sir@cmpwn.com>
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > - Rebasing. Some of our valued contributors are not 100% comfortable
> >   with the more advanced features of Git, rebasing included. Our
> >   general recommendation until now has been to prefer merge
> >   commits.
> 
> Well, one of the co-maintainers is sceptical towards rebasing, and the
> other one uses it exclusively, so I don't think we currently have any
> recommendation on the matter.

Indeed, we leave this to the individual committers.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:21                                   ` Eli Zaretskii
@ 2021-08-29  8:23                                     ` Drew DeVault
  2021-08-29  8:30                                       ` Theodor Thornhill
                                                         ` (2 more replies)
  2021-08-29  8:36                                     ` Gitlab Migration David Engster
  2021-08-29  8:37                                     ` Eli Zaretskii
  2 siblings, 3 replies; 525+ messages in thread
From: Drew DeVault @ 2021-08-29  8:23 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi

On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
> I no longer remember the exact details, it was something we bumped
> into during discussions when Emacs switched to Git. AFAIR, it had to
> do with working on a feature branch and frequently rebasing it onto
> the latest master (so that the feature branch doesn't diverge too
> much), then later merging from the feature branch to master.

Hm, weird. I would like to see some reproducible evidence of this so
that a deeper investigation can be done. I've used rebase thoroughly for
many years on hundreds of projects without any such incident.

> > This is probably something which can be done. Can you file a ticket?
> > Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
> > subject line and the body as markdown.
>
> Will do.

Thanks!



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:23                                     ` Drew DeVault
@ 2021-08-29  8:30                                       ` Theodor Thornhill
  2021-08-29  8:33                                         ` Drew DeVault
  2021-08-29 11:33                                         ` theo
  2021-08-29  8:45                                       ` Eli Zaretskii
  2021-08-29  9:09                                       ` João Távora
  2 siblings, 2 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-29  8:30 UTC (permalink / raw)
  To: Drew DeVault, Eli Zaretskii
  Cc: dgutov, larsi, danflscr, philipk, monnier, emacs-devel



On 29 August 2021 10:23:17 CEST, Drew DeVault <sir@cmpwn.com> wrote:
>On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
>> I no longer remember the exact details, it was something we bumped
>> into during discussions when Emacs switched to Git. AFAIR, it had to
>> do with working on a feature branch and frequently rebasing it onto
>> the latest master (so that the feature branch doesn't diverge too
>> much), then later merging from the feature branch to master.
>
>Hm, weird. I would like to see some reproducible evidence of this so
>that a deeper investigation can be done. I've used rebase thoroughly for
>many years on hundreds of projects without any such incident.
>

I know one way to do this, after having to untangle a coworkers mess a couple of years ago:

1. Create your branch
2. Make some commits
3. Push them because work day over
4. Next day realize you should change something
5. Edit history
6. Get message from git that remote is diverged, pull to fix
7. Get a million conflicts with old commits
8. Resolve conflicts
9. Force push
10. Since this took all day leave work
11. Go back to 4

You won't believe how crazy this case become. I've seen same commit at least 6 times in the same pr.






^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:30                                       ` Theodor Thornhill
@ 2021-08-29  8:33                                         ` Drew DeVault
  2021-08-29  8:39                                           ` Theodor Thornhill
  2021-08-29 11:33                                         ` theo
  1 sibling, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-29  8:33 UTC (permalink / raw)
  To: Theodor Thornhill, Eli Zaretskii
  Cc: philipk, danflscr, emacs-devel, monnier, dgutov, larsi

On Sun Aug 29, 2021 at 10:30 AM CEST, Theodor Thornhill wrote:
> I know one way to do this, after having to untangle a coworkers mess a
> couple of years ago:
>
> 1. Create your branch
> 2. Make some commits
> 3. Push them because work day over
> 4. Next day realize you should change something
> 5. Edit history
> 6. Get message from git that remote is diverged, pull to fix
> 7. Get a million conflicts with old commits
> 8. Resolve conflicts
> 9. Force push
> 10. Since this took all day leave work
> 11. Go back to 4
>
> You won't believe how crazy this case become. I've seen same commit at
> least 6 times in the same pr.

Are you sure you're rebasing in this scenario and not making merge
commits? If you can come up with a series of git commands which
reproduces this scenario, I would like to investigate further. Let's
follow up off-list.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:21                                   ` Eli Zaretskii
  2021-08-29  8:23                                     ` Drew DeVault
@ 2021-08-29  8:36                                     ` David Engster
  2021-08-29  8:37                                     ` Eli Zaretskii
  2 siblings, 0 replies; 525+ messages in thread
From: David Engster @ 2021-08-29  8:36 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi,
	Drew DeVault

>> How do you end up with the same commit twice?
>
> I no longer remember the exact details, it was something we bumped
> into during discussions when Emacs switched to Git.  AFAIR, it had to
> do with working on a feature branch and frequently rebasing it onto
> the latest master (so that the feature branch doesn't diverge too
> much), then later merging from the feature branch to master.

Frequently rebasing onto latest master is fine. What happened was that
people first did a 'merge-based workflow' by merging master into their
feature branch, but then later *also* decided to rebase. You mustn't mix
these two different workflow: you either regularly merge 'master' into
your feature branch, or you regularly rebase. Never do both.

-David



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:21                                   ` Eli Zaretskii
  2021-08-29  8:23                                     ` Drew DeVault
  2021-08-29  8:36                                     ` Gitlab Migration David Engster
@ 2021-08-29  8:37                                     ` Eli Zaretskii
  2 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29  8:37 UTC (permalink / raw)
  To: sir; +Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi

> Date: Sun, 29 Aug 2021 11:21:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org
> 
> > > > It depends on all of the participants Cc'ing you. It is common practice
> > > > to "reply all" on mailing lists for this reason.
> > >
> > > Too many people forget to "Reply All", we have this all the time on
> > > our current bug tracker. Is there a way to arrange for automatic
> > > subscription to a discussion once you post to that discussion?
> > 
> > This is probably something which can be done. Can you file a ticket?
> > Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
> > subject line and the body as markdown.
> 
> Will do.

Done.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:33                                         ` Drew DeVault
@ 2021-08-29  8:39                                           ` Theodor Thornhill
  0 siblings, 0 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-29  8:39 UTC (permalink / raw)
  To: Drew DeVault, Eli Zaretskii
  Cc: dgutov, larsi, danflscr, philipk, monnier, emacs-devel



On 29 August 2021 10:33:01 CEST, Drew DeVault <sir@cmpwn.com> wrote:
>On Sun Aug 29, 2021 at 10:30 AM CEST, Theodor Thornhill wrote:
>> I know one way to do this, after having to untangle a coworkers mess a
>> couple of years ago:
>>
>> 1. Create your branch
>> 2. Make some commits
>> 3. Push them because work day over
>> 4. Next day realize you should change something
>> 5. Edit history
>> 6. Get message from git that remote is diverged, pull to fix
>> 7. Get a million conflicts with old commits
>> 8. Resolve conflicts
>> 9. Force push
>> 10. Since this took all day leave work
>> 11. Go back to 4
>>
>> You won't believe how crazy this case become. I've seen same commit at
>> least 6 times in the same pr.
>
>Are you sure you're rebasing in this scenario and not making merge
>commits? If you can come up with a series of git commands which
>reproduces this scenario, I would like to investigate further. Let's
>follow up off-list.

Sure. I'll try to make a repro later today if time permits and notify you with the results.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:23                                     ` Drew DeVault
  2021-08-29  8:30                                       ` Theodor Thornhill
@ 2021-08-29  8:45                                       ` Eli Zaretskii
  2021-08-29  9:09                                       ` João Távora
  2 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29  8:45 UTC (permalink / raw)
  To: Drew DeVault; +Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi

> Date: Sun, 29 Aug 2021 10:23:17 +0200
> Cc: <dgutov@yandex.ru>, <larsi@gnus.org>, <danflscr@gmail.com>,
>  <philipk@posteo.net>, <theo@thornhill.no>, <monnier@iro.umontreal.ca>,
>  <emacs-devel@gnu.org>
> From: "Drew DeVault" <sir@cmpwn.com>
> 
> On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
> > I no longer remember the exact details, it was something we bumped
> > into during discussions when Emacs switched to Git. AFAIR, it had to
> > do with working on a feature branch and frequently rebasing it onto
> > the latest master (so that the feature branch doesn't diverge too
> > much), then later merging from the feature branch to master.
> 
> Hm, weird. I would like to see some reproducible evidence of this so
> that a deeper investigation can be done. I've used rebase thoroughly for
> many years on hundreds of projects without any such incident.

It is buried in this long discussion:

  https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01436.html

AFAIR, it had to do with "pull --rebase" as well, and the fact that
when doing the rebases in this case, Git "invents" anonymous
branches.  Or something.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:23                                     ` Drew DeVault
  2021-08-29  8:30                                       ` Theodor Thornhill
  2021-08-29  8:45                                       ` Eli Zaretskii
@ 2021-08-29  9:09                                       ` João Távora
  2021-08-29  9:53                                         ` João Távora
  2 siblings, 1 reply; 525+ messages in thread
From: João Távora @ 2021-08-29  9:09 UTC (permalink / raw)
  To: Drew DeVault
  Cc: Philip K.,
	Daniel Fleischer, Theodor Thornhill, emacs-devel, Stefan Monnier,
	Dmitry Gutov, Eli Zaretskii, Lars Ingebrigtsen

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

On Sun, Aug 29, 2021, 09:23 Drew DeVault <sir@cmpwn.com> wrote:

> On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
> > I no longer remember the exact details, it was something we bumped
> > into during discussions when Emacs switched to Git. AFAIR, it had to
> > do with working on a feature branch and frequently rebasing it onto
> > the latest master (so that the feature branch doesn't diverge too
> > much), then later merging from the feature branch to master.
>
> Hm, weird. I would like to see some reproducible evidence of this so
> that a deeper investigation can be done. I've used rebase thoroughly for
> many years on hundreds of projects without any such incident.
>

If the branch you're integrating via rebase happens to have merge commits
of its own, and you don't pass and/or fully understand what
--preserve-merges does, it's possible I think. If you always always merge,
it doesn't happen. Neither does it if you always always rebase, I guess. So
I guess the argument can be spun around into a counter-merge argument, I
guess. Anyway, I'm a rebase lover myself.

João

>

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  9:09                                       ` João Távora
@ 2021-08-29  9:53                                         ` João Távora
  2021-08-29 11:03                                           ` Merges from release branch (was: Gitlab Migration) Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: João Távora @ 2021-08-29  9:53 UTC (permalink / raw)
  To: Drew DeVault
  Cc: Philip K.,
	Daniel Fleischer, Theodor Thornhill, emacs-devel, Stefan Monnier,
	Dmitry Gutov, Eli Zaretskii, Lars Ingebrigtsen

João Távora <joaotavora@gmail.com> writes:

> On Sun, Aug 29, 2021, 09:23 Drew DeVault <sir@cmpwn.com> wrote:
>
>  On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
>  > I no longer remember the exact details, it was something we bumped
>  > into during discussions when Emacs switched to Git. AFAIR, it had to
>  > do with working on a feature branch and frequently rebasing it onto
>  > the latest master (so that the feature branch doesn't diverge too
>  > much), then later merging from the feature branch to master.
>
>  Hm, weird. I would like to see some reproducible evidence of this so
>  that a deeper investigation can be done. I've used rebase thoroughly for
>  many years on hundreds of projects without any such incident.
>
> If the branch you're integrating via rebase happens to have merge
> commits of its own, and you don't pass and/or fully understand what
> --preserve-merges does, it's possible I think. If you always always
> merge, it doesn't happen. Neither does it if you always always rebase,
> I guess. So I guess the argument can be spun around into a
> counter-merge argument, I guess. Anyway, I'm a rebase lover myself.

I just realize I "guessed" about 50 thousand times there and was
basically handwaving.  I've tried a simple example of my own speculation
just now and couldn't reproduce.  Either my toy example was too
simplistic (it involved two branches, a single file and no conflicts
ever) or it's been somehow fixed in recent Git versions.

I still think it may happen if you mix rebase & merge.  Especially if
you merge from "unreliable branches", i.e. branches whose collaborators
are not entirely aware/proficient with the commit-duplicating
consequences of rebasing and/or cherry-picking.

This is a tangent, but we also have some practice here in Emacs which I
don't fully understand, which is to "merge back from release branches"
to integrate fixes from those branches into 'main'.  That in itself
already opens the doors to "duplicated commits" if special care isn't
taken.  That's because these merges are special: they somehow don't
contain all of the stuff that was present in the release branches.  See,
for example, this commit:

    commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
    Merge: 979f14e641 5b03849102
    Author: Glenn Morris <rgm@gnu.org>
    Date:   Wed Aug 25 07:51:41 2021 -0700
     
        ; Merge from origin/emacs-27
     
        The following commit was skipped:
     
        5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...

I don't know if this practice is what constitutes an "evil merge", but
it's the way Emacs release management has worked (successfully, to the
best of my knowledge) for a good while.

João




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch (was: Gitlab Migration)
  2021-08-29  9:53                                         ` João Távora
@ 2021-08-29 11:03                                           ` Eli Zaretskii
  2021-08-29 11:14                                             ` Merges from release branch David Engster
  2021-08-29 12:29                                             ` João Távora
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29 11:03 UTC (permalink / raw)
  To: João Távora
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

> From: João Távora <joaotavora@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "Philip K." <philipk@posteo.net>,  Daniel
>  Fleischer <danflscr@gmail.com>,  Theodor Thornhill <theo@thornhill.no>,
>   emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  Dmitry Gutov <dgutov@yandex.ru>,  Lars
>  Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 29 Aug 2021 10:53:53 +0100
> 
> This is a tangent, but we also have some practice here in Emacs which I
> don't fully understand, which is to "merge back from release branches"
> to integrate fixes from those branches into 'main'.  That in itself
> already opens the doors to "duplicated commits" if special care isn't
> taken.  That's because these merges are special: they somehow don't
> contain all of the stuff that was present in the release branches.  See,
> for example, this commit:
> 
>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>     Merge: 979f14e641 5b03849102
>     Author: Glenn Morris <rgm@gnu.org>
>     Date:   Wed Aug 25 07:51:41 2021 -0700
>      
>         ; Merge from origin/emacs-27
>      
>         The following commit was skipped:
>      
>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...

What problems do you see with these merges?  I don't think I follow.

The commits are skipped either because they are marked "not to merge"
(meaning they are inappropriate for master) or because master already
has the same or a different fix.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 11:03                                           ` Merges from release branch (was: Gitlab Migration) Eli Zaretskii
@ 2021-08-29 11:14                                             ` David Engster
  2021-08-29 13:03                                               ` João Távora
  2021-08-29 12:29                                             ` João Távora
  1 sibling, 1 reply; 525+ messages in thread
From: David Engster @ 2021-08-29 11:14 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, João Távora,
	dgutov, larsi, sir, monnier

>> This is a tangent, but we also have some practice here in Emacs which I
>> don't fully understand, which is to "merge back from release branches"
>> to integrate fixes from those branches into 'main'.  That in itself
>> already opens the doors to "duplicated commits" if special care isn't
>> taken.  That's because these merges are special: they somehow don't
>> contain all of the stuff that was present in the release branches.  See,
>> for example, this commit:
>> 
>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>     Merge: 979f14e641 5b03849102
>>     Author: Glenn Morris <rgm@gnu.org>
>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>      
>>         ; Merge from origin/emacs-27
>>      
>>         The following commit was skipped:
>>      
>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...
>
> What problems do you see with these merges?  I don't think I follow.
>
> The commits are skipped either because they are marked "not to merge"
> (meaning they are inappropriate for master) or because master already
> has the same or a different fix.

I think João is confused how you would "skip" a commit in a merge,
because you actually can't. The more proper way would be to say "this
commit was separately merged with the strategy 'ours'", but this is
quite a mouthful. The merge stategy 'ours' simply means that the content
of the merged commits is discarded, but it's a perfectly valid way to
merge, so nothing "evil" about it.

-David



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  8:30                                       ` Theodor Thornhill
  2021-08-29  8:33                                         ` Drew DeVault
@ 2021-08-29 11:33                                         ` theo
  2021-08-29 19:03                                           ` Tassilo Horn
  1 sibling, 1 reply; 525+ messages in thread
From: theo @ 2021-08-29 11:33 UTC (permalink / raw)
  To: Drew DeVault, Eli Zaretskii
  Cc: dgutov, larsi, danflscr, philipk, monnier, emacs-devel

August 29, 2021 10:33 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> Are you sure you're rebasing in this scenario and not making merge
> commits? If you can come up with a series of git commands which
> reproduces this scenario, I would like to investigate further. Let's
> follow up off-list.


I'll add it as a tangent here because others seemed to chime in. You have to see this from the point of view of someone not used to git at all.

Repo with double edits: 
https://git.sr.ht/~theo/rebase/log

Ok, so what happens?

1. Make some commits, push them
2. Rebase your stuff locally, get this warning after:
```
On branch master
Your branch and 'rebase/master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean
```
(A newcomer would read this as advice)
3. git pull
4. fix conflicts if there are any
5. git add . && git commit, then save the file with commit msg
6. git push


Then you end up with the state in that repo. Timestamps are all over the place and things get hilarious real quick.

I'd consider this a bug in git, though. That message is super confusing.

This can happen in all sorts of workflows. And the fix isn't "do it correctly", since it is so simple to get wrong. When other people add things to master branch while you work on your feature it gets even worse.

Hope this helps

--
Theo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 11:03                                           ` Merges from release branch (was: Gitlab Migration) Eli Zaretskii
  2021-08-29 11:14                                             ` Merges from release branch David Engster
@ 2021-08-29 12:29                                             ` João Távora
  2021-08-29 13:18                                               ` Eli Zaretskii
  1 sibling, 1 reply; 525+ messages in thread
From: João Távora @ 2021-08-29 12:29 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  "Philip K." <philipk@posteo.net>,  Daniel
>>  Fleischer <danflscr@gmail.com>,  Theodor Thornhill <theo@thornhill.no>,
>>   emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
>>  <monnier@iro.umontreal.ca>,  Dmitry Gutov <dgutov@yandex.ru>,  Lars
>>  Ingebrigtsen <larsi@gnus.org>
>> Date: Sun, 29 Aug 2021 10:53:53 +0100
>> 
>> This is a tangent, but we also have some practice here in Emacs which I
>> don't fully understand, which is to "merge back from release branches"
>> to integrate fixes from those branches into 'main'.  That in itself
>> already opens the doors to "duplicated commits" if special care isn't
>> taken.  That's because these merges are special: they somehow don't
>> contain all of the stuff that was present in the release branches.  See,
>> for example, this commit:
>> 
>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>     Merge: 979f14e641 5b03849102
>>     Author: Glenn Morris <rgm@gnu.org>
>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>      
>>         ; Merge from origin/emacs-27
>>      
>>         The following commit was skipped:
>>      
>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...
>
> What problems do you see with these merges?  I don't think I follow.
>
> The commits are skipped either because they are marked "not to merge"
> (meaning they are inappropriate for master) or because master already
> has the same or a different fix.

I think I understand fully the reasons _why_ they are skipped.

Here's the source of my comment/confusion: normally, in a merge, I have
the expectation that the ancestors of the each branch being merged
become ancestors of the new commit, the "merge commit".  That is the way
that the vast majority of merges function.  However, for Emacs's
"skipped commits" it is sometimes only half-true, at best.

For instance, 5b038491 is, according to Git, an ancestor of 8ba6a38b3
and all 8ba6a's descendents.  However, its contents -- i.e. its diff --
are not.  At least, not exactly in the diff form as they were created,
because, as you say, they may take on a different form.  I'll add that
in the case of a bugfix commit, that bugfix may be entirely not
applicable to 'main' become the root cause of the bug being fixed has
been eliminated in the meantime.  Then the skipped commit contents would
simply not be in 'main'.

Nevertheless, a naive Git archeologist will assume 5b038491 to be in
8ba6a38b3 or its descendents, but will _not_ find its contents as easily
as he would some other non-skipped commit from some other regular merge.
If the user is lucky, she'll reach hopefully 8ba6a38b3 and read the
commit message which hopefully explains the situation: "you'd think
5b038 would be here, but it's not because reasons".

In summary, the Emacs way of doing this confuses me (and perhaps other
Git users), as I expect a merge commit to integrate fully the
developments of two or more branches.  That is, when I see it in the
DAG, I expect it to contain the contents of the two or more ancestor
branches.  Modulo conflict resolutions, where "conflict" is defined by
Git's inability to merge automatically (using whichever merge driver).
Of course a project may have sophisticated drivers and/or sophisticated
"semantic" definitions of "conflict" so that even Emacs's way of doing
this could in a way conform perfectly to my expectation if I'm
sufficently aware of those definitions.

Anyway, what could be an alternative?  Well, in other projects I work
with, these re-integrations of "release-and-dev-worthy" fixes into the
main development branch take the form of 'git cherry-pick's.  In Emacs,
this would mean cherry-picking only the "unskipped" commits.  The
cherry-picks' commit messages can be specially marked via a `-x` flag.
Arguably -- though, mind you, I'm not necessarily arguing in this
direction, just presenting an idea-- this is a means to:

* reach the same end goal: to have the release-and-dev-worthy fixes
  integrated into the main branch;

* provide more clarity to Git users who may not be familiar with the
  particular sophisticated definition of a conflict or non-default merge
  drivers.

I've seen multiple project work in this cherry-pick fashion, but I've
not done any kind of survery.  I'm unaware of what the linux kernel
does, for example.  Emacs is the only project I know that uses merges
this way, and afaik, they work fine: I've never personally had a problem
with archeology.

Hope this helps,
João






^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  3:03                   ` Richard Stallman
@ 2021-08-29 12:55                     ` Eli Zaretskii
  2021-08-30  3:01                       ` rmail threading Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29 12:55 UTC (permalink / raw)
  To: rms; +Cc: tomas, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 28 Aug 2021 23:03:22 -0400
> Cc: emacs-devel@gnu.org
> 
> Would someone like to implement Message-ID threading in Rmail?
> I would definitely appreciate it.

Is the below good enough?  If it is, I can easily code a similar
"previous-by-thread" command.

Note that this actually goes by sub-thread, i.e. it follows the
"In-Reply-To" headers, so if a thread breaks into several separate
lines of parallel discussions, this will follow only one of them.  I
think it's reasonable, given that we have rmail-next-same-subject,
which can be used to find the other sub-threads, but I'm no email
expert, so I might be missing something.

(defun rmail-next-by-thread ()
  (interactive)
  (let* ((i rmail-current-message)
         (id (rmail-get-header "message-id" i))
	 done)
    (while (and (not done) (< i rmail-total-messages))
      (setq i (1+ i)
            done (string-equal id (rmail-get-header "in-reply-to" i))))
    (if done (rmail-show-message i)
      ;; If not found forward, try backward: messages could have
      ;; arrived out of order.
      (while (and (not done) (> i 1))
	(setq i (1- i)
	      done (string-equal id (rmail-get-header "in-reply-to" i))))
      (if done (rmail-show-message i)
	(error "No further messages in this thread")))))



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 11:14                                             ` Merges from release branch David Engster
@ 2021-08-29 13:03                                               ` João Távora
  0 siblings, 0 replies; 525+ messages in thread
From: João Távora @ 2021-08-29 13:03 UTC (permalink / raw)
  To: David Engster
  Cc: philipk, danflscr, theo, emacs-devel, sir, monnier, dgutov,
	Eli Zaretskii, larsi

David Engster <deng@randomsample.de> writes:

>>> This is a tangent, but we also have some practice here in Emacs which I
>>> don't fully understand, which is to "merge back from release branches"
>>> to integrate fixes from those branches into 'main'.  That in itself
>>> already opens the doors to "duplicated commits" if special care isn't
>>> taken.  That's because these merges are special: they somehow don't
>>> contain all of the stuff that was present in the release branches.  See,
>>> for example, this commit:
>>> 
>>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>>     Merge: 979f14e641 5b03849102
>>>     Author: Glenn Morris <rgm@gnu.org>
>>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>>      
>>>         ; Merge from origin/emacs-27
>>>      
>>>         The following commit was skipped:
>>>      
>>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...
>>
>> What problems do you see with these merges?  I don't think I follow.
>>
>> The commits are skipped either because they are marked "not to merge"
>> (meaning they are inappropriate for master) or because master already
>> has the same or a different fix.
>
> I think João is confused how you would "skip" a commit in a merge,
> because you actually can't.

Precisely, though I'm reasonably aware of why and how its done.  I've
explained what I find "confusing" or "peculiar" about it in a longer
email to Esli.

>The more proper way would be to say "this
> commit was separately merged with the strategy 'ours'", but this is
> quite a mouthful. The merge stategy 'ours' simply means that the content
> of the merged commits is discarded, but it's a perfectly valid way to
> merge, so nothing "evil" about it.

I think "evil" as an adjective is suitably exaggerated to characterize
merges where some semantic knowledge of the source (vs Git's purely
formal knowledge) of it, was applied to solve a particular definition of
a "conflict".  Those definitions and semantic insights differ from the
Git defaults, which is concerned with line ranges and hunks.  Newcomer
Git archeologists thus don't have good way to know what kind of merge
they're looking at, short of reading commit messages carefully and or
perusing project documentation.  Moreover the non-defualt merge
techniques may be inconsistently applied across commiters or across time
spans.  In short, this Fear-Uncertainty-Doubt is what could be called
"evil" in a sense.

Of course, if everybody has a full understanding of practices, and
definitions and behaves and follows rules, no FUD exists and nothing
"evil" ever takes place.  But that is a big "if".

João

PS: the 'man gitglossary' definition of an "evil merge" is "a merge that
introduces changes that do not appear in any parent."  I do think this
comprises "removing code that appears in some parent", because that
removal is the introduction of a change that was absent before the merge
commit and present after it.  Linus Torvalds definition is more
sophisticated and better, IMO.  According to [1], he says:

  an "evil merge" is something that makes changes that came from neither
  side and aren't actually resolving a conflict.

In this definition, the concept of "conflict" appears.  Depending on how
you massage that concept, nothing is evil and everything is.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 12:29                                             ` João Távora
@ 2021-08-29 13:18                                               ` Eli Zaretskii
  2021-08-29 14:48                                                 ` João Távora
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29 13:18 UTC (permalink / raw)
  To: João Távora
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 13:29:27 +0100
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> Here's the source of my comment/confusion: normally, in a merge, I have
> the expectation that the ancestors of the each branch being merged
> become ancestors of the new commit, the "merge commit".  That is the way
> that the vast majority of merges function.  However, for Emacs's
> "skipped commits" it is sometimes only half-true, at best.

No, it's always true, AFAIU.

> For instance, 5b038491 is, according to Git, an ancestor of 8ba6a38b3
> and all 8ba6a's descendents.  However, its contents -- i.e. its diff --
> are not.

I think you are confusing between the ancestry in the DAG sense of the
word, on the one hand, and the contents of the merged commits, OTOH.

> In summary, the Emacs way of doing this confuses me (and perhaps other
> Git users), as I expect a merge commit to integrate fully the
> developments of two or more branches.

Welcome to Git: IME, Git without confusion doesn't exist.

We use the merge workflow because it's the easiest and the less
dangerous one.  We know for a long time that it sometimes produces
confusing and/or suboptimal DAG, but we decided long ago that this is
the price we are prepared to pay in order to make routine usage less
error-prone for those users who are not Git experts and basically use
Git commands as a cookbook they don't always understand 100%.

> Anyway, what could be an alternative?

We examined the alternatives when we switched to Git, and decided they
all are either more complicated, or more dangerous, or both.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 13:18                                               ` Eli Zaretskii
@ 2021-08-29 14:48                                                 ` João Távora
  2021-08-29 14:59                                                   ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: João Távora @ 2021-08-29 14:48 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

Eli Zaretskii <eliz@gnu.org> writes:

> I think you are confusing between the ancestry in the DAG sense of the
> word, on the one hand, and the contents of the merged commits, OTOH.

What I'm trying to tell you is that -- by default -- in Git, merging
_means_ composition of contents of the ancestors, modulo trivial
patch-application conflicts.  So there's a clear relation between the
two things: DAG ancestry and code contents.  Git allows you to invent
arbitrary meanings for merging, but deviating from the default is
confusing to... those who expect the default.

> We examined the alternatives when we switched to Git, and decided they
> all are either more complicated, or more dangerous, or both.

Of course, there are cons to everything: integrating back by
cherry-picking involves creating different commits with the same
headline&contents, so that if you have many 'emacs-2x' commits to
integrate back they all appear again in 'main' (but never twice in
'main').  That could be tiresome to some.  Also, with cherry-picks
alone, there's no clear way to tell from the DAG when Glenn decided to
"integrate back" like there is now.  However someone could argue that
those cons are outweighed by the fact that no merge commits exists and
that ancestry at a given point of the DAG now tells any Git user which
code changes are operating at a given point.

As to a specific "danger", I'm intrigued.  Like Drew, would have to see
a particular "dangerous" scenario before I can comment on it.  The
enormous Git threads of 5-6 years ago I remember are too daunting to
re-read.

João



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 14:48                                                 ` João Távora
@ 2021-08-29 14:59                                                   ` Eli Zaretskii
  2021-08-29 15:21                                                     ` João Távora
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29 14:59 UTC (permalink / raw)
  To: João Távora
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 15:48:22 +0100
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> As to a specific "danger", I'm intrigued.  Like Drew, would have to see
> a particular "dangerous" scenario before I can comment on it.  The
> enormous Git threads of 5-6 years ago I remember are too daunting to
> re-read.

Then you'll have to trust me on that one.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 14:59                                                   ` Eli Zaretskii
@ 2021-08-29 15:21                                                     ` João Távora
  2021-08-29 15:55                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: João Távora @ 2021-08-29 15:21 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Philip K.,
	Daniel Fleischer, Theodor Thornhill, emacs-devel, Stefan Monnier,
	Dmitry Gutov, Lars Ingebrigtsen, sir

On Sun, Aug 29, 2021 at 3:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sun, 29 Aug 2021 15:48:22 +0100
> > Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
> >  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
> >  larsi@gnus.org, sir@cmpwn.com
> >
> > As to a specific "danger", I'm intrigued.  Like Drew, would have to see
> > a particular "dangerous" scenario before I can comment on it.  The
> > enormous Git threads of 5-6 years ago I remember are too daunting to
> > re-read.
>
> Then you'll have to trust me on that one.

For Emacs, sure. Even if our integration scheme is somewhat peculiar,
it is at least very well done, well documented, and I've never had
problems. I'm really quite happy with Git in Emacs and excited about
this recent inclination to SourceHut.

Of course I wonder if there's something special in Emacs it that makes it
somehow vulnerable to more commonly found integration strategies, or,
alternatively, if the danger you're imagining is something to worry about
for any other projects that utilizes them.

João



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 15:21                                                     ` João Távora
@ 2021-08-29 15:55                                                       ` Eli Zaretskii
  2021-08-29 15:58                                                         ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29 15:55 UTC (permalink / raw)
  To: João Távora
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 16:21:30 +0100
> Cc: "Philip K." <philipk@posteo.net>, Daniel Fleischer <danflscr@gmail.com>,
>  Theodor Thornhill <theo@thornhill.no>, emacs-devel <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <dgutov@yandex.ru>,
>  Lars Ingebrigtsen <larsi@gnus.org>, sir@cmpwn.com
> 
> Of course I wonder if there's something special in Emacs it that makes it
> somehow vulnerable to more commonly found integration strategies, or,
> alternatively, if the danger you're imagining is something to worry about
> for any other projects that utilizes them.

The discussions at the time were long, detailed, and raised several
loosely-related issues, all of them in the context of what to say in
the document we were composing that described the recommended
procedures.  I don't remember the details, sorry.  Once we understood
the issues and made the decision, there was no need for me to keep
those details in memory.  Maybe David or someone else remembers; if
not, there's no way around the need to read those discussions.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Merges from release branch
  2021-08-29 15:55                                                       ` Eli Zaretskii
@ 2021-08-29 15:58                                                         ` Eli Zaretskii
  0 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-29 15:58 UTC (permalink / raw)
  To: joaotavora
  Cc: philipk, danflscr, theo, emacs-devel, monnier, dgutov, larsi, sir

> Date: Sun, 29 Aug 2021 18:55:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> > Of course I wonder if there's something special in Emacs it that makes it
> > somehow vulnerable to more commonly found integration strategies, or,
> > alternatively, if the danger you're imagining is something to worry about
> > for any other projects that utilizes them.
> 
> The discussions at the time were long, detailed, and raised several
> loosely-related issues, all of them in the context of what to say in
> the document we were composing that described the recommended
> procedures.  I don't remember the details, sorry.  Once we understood
> the issues and made the decision, there was no need for me to keep
> those details in memory.  Maybe David or someone else remembers; if
> not, there's no way around the need to read those discussions.

Oh, and the only aspect in those discussions that was specific to
Emacs, AFAIR, was that we have 2 branches that diverge very quickly.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-29  7:10                             ` Drew DeVault
@ 2021-08-29 18:30                               ` Ben Mezger
  2021-08-30  2:59                                 ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Ben Mezger @ 2021-08-29 18:30 UTC (permalink / raw)
  To: Drew DeVault
  Cc: philipk, danflscr, rms, theo, emacs-devel, monnier, tsdh, larsi,
	eliz, spwhitton


> It would be nice to have the emacs vote of confidence in our services,
> in the strategic sense of mutual support between organizations which
> believe in free software.

Drew summarized what I've meant with "first move". Emacs migration
towards a service like sourcehut may contribute to the confidence
and motivation of other projects to follow a similar approach.

"Drew DeVault" <sir@cmpwn.com> writes:

> On Sun Aug 29, 2021 at 5:03 AM CEST, Richard Stallman wrote:
>> > Maybe if Emacs makes the first move, perhaps other projects may follow
>> > the same path.
>>
>> Sorry -- what is "first move" that is being proposed?
>>
>> We want to host Emacs on a GNU server, not someone else's.
>
> You can run the sourcehut software on GNU servers, it is 100% free
> software, mostly AGPL. I would encourage you to do so.
>
> However, I think that this is a rare case where you could also use our
> servers if you so desired. The software on our servers is not patched,
> it's the same free software you would run on yours. If you did some
> reading on sourcehut, I think you would find our philosophy quite
> compatible with GNU's ideals. It would be nice to have the emacs vote of
> confidence in our services, in the strategic sense of mutual support
> between organizations which believe in free software.
>
> SourceHut is a straight upgrade from the existing mailing lists, and
> supports the existing workflow almost 1:1, perhaps pending some minor
> enhancements around attachments. The web tools to accomodate the
> pull-request generation are at a prototype stage, but will be improved.
> The free software ethic is here to stay.


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

Ben Mezger

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



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  3:00             ` Richard Stallman
@ 2021-08-29 18:40               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-29 18:40 UTC (permalink / raw)
  To: Richard Stallman
  Cc: philipk, danflscr, emacs-devel, joaotavora, arthur.miller, eliz

Richard Stallman <rms@gnu.org> writes:

>   > We haven't found such a system yet.  sr.ht is perhaps an option, but my
>   > first impression is that it's too different from GitHub/Lab, really.
>
> Why should such a difference disqualify it?  We have no commitment to
> GitHub/Lab; on the contrary, we disapprove of them.

The main point of this exercise is to provide new Emacs workflows that
people used to, and comfortable with using.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29 11:33                                         ` theo
@ 2021-08-29 19:03                                           ` Tassilo Horn
  2021-08-29 19:50                                             ` Theodor Thornhill
  0 siblings, 1 reply; 525+ messages in thread
From: Tassilo Horn @ 2021-08-29 19:03 UTC (permalink / raw)
  To: theo
  Cc: philipk, danflscr, Drew DeVault, monnier, dgutov, larsi,
	emacs-devel, Eli Zaretskii

theo@thornhill.no writes:

Hi Theo,

> Repo with double edits: 
> https://git.sr.ht/~theo/rebase/log
>
> Ok, so what happens?
>
> 1. Make some commits, push them
> 2. Rebase your stuff locally, get this warning after:

Well, looking at "git log --graph" of your repo, I'm pretty sure you
ended there because in step 2 you rebased commits which you had already
pushed and later merged the upstream branch with the locally rebased
one.  Rebasing commits which are already pushed is a no-go unless you
are working in your private branch.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29 19:03                                           ` Tassilo Horn
@ 2021-08-29 19:50                                             ` Theodor Thornhill
  0 siblings, 0 replies; 525+ messages in thread
From: Theodor Thornhill @ 2021-08-29 19:50 UTC (permalink / raw)
  To: Tassilo Horn
  Cc: Drew DeVault, Eli Zaretskii, dgutov, larsi, danflscr, philipk,
	monnier, emacs-devel



On 29 August 2021 21:03:45 CEST, Tassilo Horn <tsdh@gnu.org> wrote:
>theo@thornhill.no writes:
>
>Hi Theo,
>
>> Repo with double edits: 
>> https://git.sr.ht/~theo/rebase/log
>>
>> Ok, so what happens?
>>
>> 1. Make some commits, push them
>> 2. Rebase your stuff locally, get this warning after:
>
>Well, looking at "git log --graph" of your repo, I'm pretty sure you
>ended there because in step 2 you rebased commits which you had already
>pushed and later merged the upstream branch with the locally rebased
>one.  Rebasing commits which are already pushed is a no-go unless you
>are working in your private branch.
>

Yeah, absolutely. Thing is these things happen to people and are possibly why people find git hard. At least when your gui hides the fact that git pull is fetch and merge behind a +button, or something like that.

And this is also a way to get duplicated commits without doing very complicated footgun things. Git itself hands you the gun in this case.

Theo





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  7:42                             ` Lars Ingebrigtsen
  2021-08-29  8:22                               ` Eli Zaretskii
@ 2021-08-29 21:13                               ` Dmitry Gutov
  1 sibling, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-29 21:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: Philip Kaludercic, danflscr, theo, emacs-devel, monnier,
	Eli Zaretskii, Drew DeVault

On 29.08.2021 10:42, Lars Ingebrigtsen wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> - Rebasing. Some of our valued contributors are not 100% comfortable
>>    with the more advanced features of Git, rebasing included. Our
>>    general recommendation until now has been to prefer merge
>>    commits.
> Well, one of the co-maintainers is sceptical towards rebasing, and the
> other one uses it exclusively, so I don't think we currently have any
> recommendation on the matter.

Whenever a question arose about a recommended workflow from someone who 
claims not to understand Git well, the recommendation always came in the 
form "use merges, not rebase". Which is a good suggestion, I think.

A well-done rebase is indistinguishable from a "normal" branch, so of 
course there is no point in prohibiting their use.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  7:42                                 ` Drew DeVault
  2021-08-29  8:21                                   ` Eli Zaretskii
@ 2021-08-29 22:27                                   ` Dmitry Gutov
  2021-08-30  6:31                                     ` Drew DeVault
  1 sibling, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-29 22:27 UTC (permalink / raw)
  To: Drew DeVault, Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, larsi

On 29.08.2021 10:42, Drew DeVault wrote:
> On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
>> Rebasing is not just intimidating, it has real problems as well. One
>> problem that particularly bothers us is that it could, in some
>> circumstances, cause the same commit to be present more than once.
>>
>> I find a hard requirement to use rebase to be user-unfriendly, because
>> some of us simply don't want to rebase, for reasons of preserving the
>> original history of the development. Is rebasing really a requirement
>> in SourceHut?
> No, it's not a requirement. It's just something I think is a good idea.

When you say it's not a requirement, how does the alternative work?

Suppose I have a feature branch scratch/exciting-new-feature.

And it has a number of existing commits A, B, C, where I did some work 
on said feature.

Then I do a merge from master, creating a merge commit M which resolves 
a conflict. It also pulls commits M1 and M2 from master into the branch, 
both of which have a later creation date than A.

Then I add commits D and E with some subsequent work.

What do I do next, to submit the new version of the code?

If I try to submit that branch's contents from the web UI, and I need to 
select all the commits which include the work:

- Does the Prepare Patchset UI show commits M1 and M2? What happens if 
they get selected (residing chronologically between A and E)?

- Does the Prepare Patchset UI show the merge commit M? If yes, what 
happens with it later if the patchset gets approved? Does it turn into a 
"real" merge commit?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  6:55                             ` Drew DeVault
  2021-08-29  7:38                               ` Eli Zaretskii
@ 2021-08-29 23:17                               ` Dmitry Gutov
  2021-08-30  6:29                                 ` Drew DeVault
  1 sibling, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-29 23:17 UTC (permalink / raw)
  To: Drew DeVault, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On 29.08.2021 09:55, Drew DeVault wrote:

>> - Every version of a patchset is re-submitted as a whole. I suppose
>> there is some purity in that, but if for example the original submission
>> is big, and I only asked the author to change a few relatively minor
>> things, I prefer they do that in a separate commit. Then, in a git**b
>> workflow, I see that the branch was updated with that one commit, and I
>> don't have to scan the other commit(s) for any unrelated/breaking
>> changes.
> 
> This is a bad practice for git, because it makes the history worse. This
> has consequences, for example, with tools like git bisect.

Depends on how the changes are organized, whether there will be breaking 
builds, and whether commits include back-and-forth changes in the same 
place.

In the end, a branch-driven workflow can ask for a single rebase before 
the changes are merged to master (with fixups, squashes, etc). Which 
should fix the later problems with bisecting and give cleaner history, 
without having all the patches resent for every round of review.

> Instead, git
> range-diff is helpful for comparing the previous and new version of a
> patch, and future improvements to the web UI will incorporate it to
> allow you to easily diff between patchset revisions. The idea is
> something similar to Gerrit's approach, you may be familiar with that.

Haven't used Gerrit (or Phabricator, which I understand includes a 
similar feature). Good to know there is a plan for it, though.

>> - Rebasing. Some of our valued contributors are not 100% comfortable
>> with the more advanced features of Git, rebasing included. Our general
>> recommendation until now has been to prefer merge commits. If the
>> general workflow is going to require people to 'git rebase -i' on a
>> regular basis, it could be a problem.
> 
> We wrote another tutorial about git rebase which has been very helpful:
> 
> https://git-rebase.io
> 
> In general we are a hard "no" on shying away from powerful tools because
> they are intimidating to new users. We prefer to cultivate a culture of
> mentorship instead.

All right. I can live with that. Just want to make sure everybody's on 
the same page about the tradeoffs.

>> - Can we have discussion subthreads "attached" to particular pieces of
>> the submitted patches? Like, a line, or a hunk. Being able to view those
>> in a compact fashion, right in the middle of the context, is pretty
>> handy.
> 
> Yes, though it's based on heuristics and we're still working on it.
> Here's a simple example:
> 
> https://lists.sr.ht/~mpu/qbe/patches/24383

Thanks. I'm curious to see how it turns out.

>> - Can I jump in in the middle of a patch discussion with a question or
>> an advice and have all subsequent messages in that discussion sent to me
>> too, if I'm not subscribed to the target mailing list? Does that depend
>> on all participants putting me in Cc?
> 
> It depends on all of the participants Cc'ing you. It is common practice
> to "reply all" on mailing lists for this reason.

Sure, I'm familiar with it. Hence the questions.

>> - Can I do that "jumping in" from the web interface?
> 
> No, but this is a prioritized issue.
> 
>> - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
>> longer interested in?
> 
> In a sense. Because you don't have to subscribe to the mailing list to
> participate in a thread, you won't get emails unless the sender has Cc'd
> you. But you cannot stop them from Cc'ing you, and neither can we,
> unless you ask nicely - which is not a software solution. Such emails
> are not relayed by our mail servers, so it's out of our control.

Consider adopting a "common practice" from the Web UI world: every 
discussion (issue/PR/etc) has a unique email address. Every participant 
receives messages "From:" a common address (like notifications@sr.ht) 
but the Reply-To header includes the unique address which will let the 
mail processor on the server associate the reply with the corresponding 
thread and resend it to all participants.

Then anybody will be able to subscribe or unsubscribe from a thread 
without others' cooperation (with different levels, even, where e.g. 
they still get a notification when "mentioned" personally).

As a bonus, it solves the problem of some mail servers/hostings not 
talking to some other mail servers: if you can send an email to sr.ht, 
all others will see it. If you can receive emails from sr.ht, you will 
get all messages.

But it might feel a tad impersonal, I guess. And user error (including 
misbehaving MUAs) can break this approach too.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29  2:27             ` Dmitry Gutov
@ 2021-08-30  2:58               ` Richard Stallman
  2021-08-30 12:20                 ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-30  2:58 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: eliz, emacs-devel, danflscr, philipk, monnier

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

  >  perhaps even an ability to write messages from 
  > the browser (which is certain to appeal to some newcomers).

It is fine to offer this feature, provided the message turns into
email so that we can receive it in our inboxes.  Is that the case?

  > Overall, if we finally accept that neither UI familiarity (for new 
  > users) nor workflow familiarity (for new contributors) are a priority 
  > for the Emacs project, this might a reasonable option to migrate to.

They count for something, but less than many other countervaling values.
This is meaningful at the "all else being equal" level.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-29  3:18                         ` Drew Adams
@ 2021-08-30  2:59                           ` Richard Stallman
  0 siblings, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-30  2:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: theophilusx, danflscr, arthur.miller, emacs-devel

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

  > > They feel simplistic, overly dismissive and
  > > somewhat arrogant. 

  > That's exactly what that comment you just made
  > feels like.  Your complaint does what it
  > complains about.

What this says to me is that it isn't a matter of a substantive
issue on which someone is right or wrong.  It's that we've fallen
into a pattern of not being kind to each other, and retaliating
to each other.

Maybe it would be useful for various people to look at the messages
they have previously written, and look for ways to have said
them more kindly.

See https://gnu.org/philosophy/kind-communication.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)





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: GitLab feature request compared with SourceHut
  2021-08-29 18:30                               ` Ben Mezger
@ 2021-08-30  2:59                                 ` Richard Stallman
  0 siblings, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-08-30  2:59 UTC (permalink / raw)
  To: Ben Mezger
  Cc: philipk, danflscr, theo, emacs-devel, eliz, monnier, tsdh, larsi,
	sir, spwhitton

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

  > Drew summarized what I've meant with "first move".

Thanks for showing me that.

                                                       Emacs migration
  > towards a service like sourcehut may contribute to the confidence
  > and motivation of other projects to follow a similar approach.

We could switch to using the sourcehut software on a GNU server.

I think Drew DeVault is right in saying that his philosophy is close
to ours.  If we had to use some outside hosting service, I might well
say there is no better choice than his.  (I don't want to criticize
the other options without knowing what they are; they may be equally
good.)  But we'd rather have this on a GNU machine with GNU Project
people managing it.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* rmail threading
  2021-08-29 12:55                     ` Eli Zaretskii
@ 2021-08-30  3:01                       ` Richard Stallman
  2021-08-30 12:07                         ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-30  3:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: tomas, emacs-devel

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

  > Is the below good enough?  If it is, I can easily code a similar
  > "previous-by-thread" command.

It is a start, but what is really needed is a summary command
to generate a summary containing the messages of a thread established
by message-IDs.

In fact, I never use rmail-next-same-subject; I don't even remember
it is there.  I always use rmail-summary-by-topic, after which
I can see all the messages of the thread-by-subject.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29 23:17                               ` Dmitry Gutov
@ 2021-08-30  6:29                                 ` Drew DeVault
  2021-08-30 12:47                                   ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-30  6:29 UTC (permalink / raw)
  To: Dmitry Gutov, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On Mon Aug 30, 2021 at 1:17 AM CEST, Dmitry Gutov wrote:
> Consider adopting a "common practice" from the Web UI world: every
> discussion (issue/PR/etc) has a unique email address. Every participant
> receives messages "From:" a common address (like notifications@sr.ht)
> but the Reply-To header includes the unique address which will let the
> mail processor on the server associate the reply with the corresponding
> thread and resend it to all participants.

We cannot add a similar "common practice", as it were, where each
message comes From notifications@sr.ht, without breaking DKIM or PGP
signatures, which we refuse to do. But, we can track participation in
each thread and subscribe users to threads even without a specific email
address, by linking up the In-Reply-To chain. This is how I envision
your ticket being addressed.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-29 22:27                                   ` Dmitry Gutov
@ 2021-08-30  6:31                                     ` Drew DeVault
  2021-08-30 12:32                                       ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-30  6:31 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, larsi

On Mon Aug 30, 2021 at 12:27 AM CEST, Dmitry Gutov wrote:
> When you say it's not a requirement, how does the alternative work?
>
> Suppose I have a feature branch scratch/exciting-new-feature.
>
> And it has a number of existing commits A, B, C, where I did some work
> on said feature.
>
> Then I do a merge from master, creating a merge commit M which resolves
> a conflict. It also pulls commits M1 and M2 from master into the branch,
> both of which have a later creation date than A.
>
> Then I add commits D and E with some subsequent work.

Honestly, by doing this you have created a poor git history which I, as
a maintainer, would not care to review, be it via email or any other
means including the GitHub workflow. I would teach you how to rebase it
properly instead of accepting this work, and I think that emacs would be
wise to do the same.

However, you can still work with this on sourcehut by using git
request-pull(1):

https://www.git-scm.com/docs/git-request-pull

There is no UI for this, but it is planned.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* gebbugs.gnu.org search (was Re: Gitlab Migration)
  2021-08-27  6:21               ` tomas
  2021-08-27  7:23                 ` Debbugs state (was: [External] : Re: Gitlab Migration) Michael Albinus
@ 2021-08-30 11:42                 ` Maxim Nikulin
  2021-08-30 15:30                   ` debbugs.gnu.org search [was gebbugs.gnu.org search] Glenn Morris
  1 sibling, 1 reply; 525+ messages in thread
From: Maxim Nikulin @ 2021-08-30 11:42 UTC (permalink / raw)
  To: emacs-devel

On 27/08/2021 13:21, tomas tuxteam.de wrote:
> On Thu, Aug 26, 2021 at 09:41:06PM +0000, Drew Adams wrote:
> 
>> 5. And debbugs.gnu.org search sucks.  Or at least I suck
>> at trying to find anything using it.
> 
> My starting point would be something like [1].
...
> [1] https://html.duckduckgo.com/html?q=redisplay+idle+site:debbugs.gnu.org

Does it work for you? I get titles like
- "GNU bug reports: Normal bugs - outstanding"
- "GNU bug report logs - #17678"
and links to raw mail messages, e.g. debbugs.gnu.org/db/17/17678.html

I have no idea what should be find by your request, so let's consider 
another one:

https://html.duckduckgo.com/html?q=site%3Adebbugs.gnu.org+emacs+locale+number

For this particular query I expect to get

     *#29645 Feature Request: Locale aware formatting*
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645

among top results. Actually I would not mind to get it without narrowing 
search to debbugs.gnu.org.

It seems, google has no chance to provide relevant human friendly 
results due to

https://debbugs.gnu.org/robots.txt
 > Disallow: /cgi/

Configuration of Debian bug tracker is better:
https://bugs.debian.org/robots.txt
 > Allow: /cgi-bin/bugreport.cgi?bug=




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: rmail threading
  2021-08-30  3:01                       ` rmail threading Richard Stallman
@ 2021-08-30 12:07                         ` Eli Zaretskii
  2021-08-31  3:09                           ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-30 12:07 UTC (permalink / raw)
  To: rms; +Cc: tomas, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Sun, 29 Aug 2021 23:01:51 -0400
> 
>   > Is the below good enough?  If it is, I can easily code a similar
>   > "previous-by-thread" command.
> 
> It is a start, but what is really needed is a summary command
> to generate a summary containing the messages of a thread established
> by message-IDs.

Ah, you want an Rmail summary command for this...  OK, will do.

In any case, my original naïve attempt was wrong, because even
sub-threads have the tree structure, they aren't linear lists.  So
we'd need a tree-traversing code, not unlike what SPC and DEL do in
Info.

> In fact, I never use rmail-next-same-subject; I don't even remember
> it is there.  I always use rmail-summary-by-topic, after which
> I can see all the messages of the thread-by-subject.

I prefer not to review a thread via a summary, because a specialized
summary prevents me from easily seeing messages that don't satisfy the
summary criteria.  This is important with criteria based on fuzzy
stuff like the Subject, because people or their MUA many times change
or mangle the Subject, and then those messages appear not to be there.
But that's me.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30  2:58               ` Richard Stallman
@ 2021-08-30 12:20                 ` Dmitry Gutov
  2021-08-30 12:48                   ` Daniel Fleischer
  2021-08-31  3:09                   ` Richard Stallman
  0 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-30 12:20 UTC (permalink / raw)
  To: rms; +Cc: eliz, emacs-devel, danflscr, philipk, monnier

On 30.08.2021 05:58, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    >  perhaps even an ability to write messages from
>    > the browser (which is certain to appeal to some newcomers).
> 
> It is fine to offer this feature, provided the message turns into
> email so that we can receive it in our inboxes.  Is that the case?

That's the idea.

>    > Overall, if we finally accept that neither UI familiarity (for new
>    > users) nor workflow familiarity (for new contributors) are a priority
>    > for the Emacs project, this might a reasonable option to migrate to.
> 
> They count for something, but less than many other countervaling values.
> This is meaningful at the "all else being equal" level.

Yes, as is now apparent from multiple arguments around the subject, 
appealing to newcomers (and/or trying to adopt contemporary usability 
practices) is of much lesser priority than, say, making sure that each 
key binding that has been with us for a number of years, is left 
unchanged for ever. We hate to risk inconveniencing existing users.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30  6:31                                     ` Drew DeVault
@ 2021-08-30 12:32                                       ` Dmitry Gutov
  0 siblings, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-30 12:32 UTC (permalink / raw)
  To: Drew DeVault, Eli Zaretskii
  Cc: philipk, danflscr, theo, emacs-devel, monnier, larsi

On 30.08.2021 09:31, Drew DeVault wrote:
> On Mon Aug 30, 2021 at 12:27 AM CEST, Dmitry Gutov wrote:
>> When you say it's not a requirement, how does the alternative work?
>>
>> Suppose I have a feature branch scratch/exciting-new-feature.
>>
>> And it has a number of existing commits A, B, C, where I did some work
>> on said feature.
>>
>> Then I do a merge from master, creating a merge commit M which resolves
>> a conflict. It also pulls commits M1 and M2 from master into the branch,
>> both of which have a later creation date than A.
>>
>> Then I add commits D and E with some subsequent work.
> 
> Honestly, by doing this you have created a poor git history which I, as
> a maintainer, would not care to review, be it via email or any other
> means including the GitHub workflow. I would teach you how to rebase it
> properly instead of accepting this work, and I think that emacs would be
> wise to do the same.

So far it has been common practice around these parts, but OK.

> However, you can still work with this on sourcehut by using git
> request-pull(1):
> 
> https://www.git-scm.com/docs/git-request-pull
> 
> There is no UI for this, but it is planned.

Thanks.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30  6:29                                 ` Drew DeVault
@ 2021-08-30 12:47                                   ` Dmitry Gutov
  2021-08-30 12:49                                     ` Drew DeVault
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-30 12:47 UTC (permalink / raw)
  To: Drew DeVault, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On 30.08.2021 09:29, Drew DeVault wrote:
> On Mon Aug 30, 2021 at 1:17 AM CEST, Dmitry Gutov wrote:
>> Consider adopting a "common practice" from the Web UI world: every
>> discussion (issue/PR/etc) has a unique email address. Every participant
>> receives messages "From:" a common address (like notifications@sr.ht)
>> but the Reply-To header includes the unique address which will let the
>> mail processor on the server associate the reply with the corresponding
>> thread and resend it to all participants.
> 
> We cannot add a similar "common practice", as it were, where each
> message comes From notifications@sr.ht, without breaking DKIM or PGP
> signatures, which we refuse to do.

This is about sender identity verification, right? No chance to delegate 
that responsibility to the SourceHut instance?

If the web interface allows users to create patchset email on behalf of 
the user, or even send messages to the mailing list from the web UI (not 
sure if such feature is present, but there will be a demand for it), you 
are already creating emails on their behalf anyway.

> But, we can track participation in
> each thread and subscribe users to threads even without a specific email
> address, by linking up the In-Reply-To chain. This is how I envision
> your ticket being addressed.

Will that affect only replies to later emails?

Either way, that means no reliable way to "unsubscribe from a thread". 
Unfortunate, but of course less important that being able to subscribe.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 12:20                 ` Dmitry Gutov
@ 2021-08-30 12:48                   ` Daniel Fleischer
  2021-08-30 12:55                     ` Dmitry Gutov
  2021-08-31  3:09                   ` Richard Stallman
  1 sibling, 1 reply; 525+ messages in thread
From: Daniel Fleischer @ 2021-08-30 12:48 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, eliz, emacs-devel, rms, monnier

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

Dmitry Gutov [2021-08-30 Mon 15:20]  wrote:

> Yes, as is now apparent from multiple arguments around the subject, appealing to newcomers (and/or trying to adopt
> contemporary usability practices) is of much lesser priority than, say, making sure that each key binding that has been
> with us for a number of years, is left unchanged for ever. We hate to risk inconveniencing existing users.

Key bindings are important!


*Daniel Fleischer*

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 12:47                                   ` Dmitry Gutov
@ 2021-08-30 12:49                                     ` Drew DeVault
  2021-08-30 13:00                                       ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-30 12:49 UTC (permalink / raw)
  To: Dmitry Gutov, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On Mon Aug 30, 2021 at 2:47 PM CEST, Dmitry Gutov wrote:
> This is about sender identity verification, right? No chance to delegate
> that responsibility to the SourceHut instance?
>
> If the web interface allows users to create patchset email on behalf of
> the user, or even send messages to the mailing list from the web UI (not
> sure if such feature is present, but there will be a demand for it), you
> are already creating emails on their behalf anyway.

We find it important to preserve the original integrity of the email.
This is important for a robust and reliable mail system.

> Will that affect only replies to later emails?

Yes.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 12:48                   ` Daniel Fleischer
@ 2021-08-30 12:55                     ` Dmitry Gutov
  2021-09-03  4:57                       ` Elias Mårtenson
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-30 12:55 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: philipk, eliz, emacs-devel, rms, monnier

On 30.08.2021 15:48, Daniel Fleischer wrote:
> Dmitry Gutov [2021-08-30 Mon 15:20]  wrote:
> 
>> Yes, as is now apparent from multiple arguments around the subject, appealing to newcomers (and/or trying to adopt
>> contemporary usability practices) is of much lesser priority than, say, making sure that each key binding that has been
>> with us for a number of years, is left unchanged for ever. We hate to risk inconveniencing existing users.
> Key bindings are important!

The question is, important for what.

And whether existing muscle memory can be sacrificed for better 
usability. And/or for reduced suffering in newcomers.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 12:49                                     ` Drew DeVault
@ 2021-08-30 13:00                                       ` Dmitry Gutov
  2021-08-30 13:03                                         ` Drew DeVault
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-30 13:00 UTC (permalink / raw)
  To: Drew DeVault, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On 30.08.2021 15:49, Drew DeVault wrote:
>> Will that affect only replies to later emails?
> Yes.

I think that can be fixed in the mailing list software layer: if an 
email is addressed to a thread, and there are some ostensibly 
"subscribed" users that are missing from the list of recipients, send it 
to them too.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 13:00                                       ` Dmitry Gutov
@ 2021-08-30 13:03                                         ` Drew DeVault
  2021-08-30 13:06                                           ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Drew DeVault @ 2021-08-30 13:03 UTC (permalink / raw)
  To: Dmitry Gutov, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On Mon Aug 30, 2021 at 3:00 PM CEST, Dmitry Gutov wrote:
> On 30.08.2021 15:49, Drew DeVault wrote:
> >> Will that affect only replies to later emails?
> > Yes.
>
> I think that can be fixed in the mailing list software layer: if an
> email is addressed to a thread, and there are some ostensibly
> "subscribed" users that are missing from the list of recipients, send it
> to them too.

Yes, this would work, but only for later emails. I certainly would not
want to try and apply it retroactively by emailing someone 100 messages
after they chime in at the end of a large thread.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 13:03                                         ` Drew DeVault
@ 2021-08-30 13:06                                           ` Dmitry Gutov
  0 siblings, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-30 13:06 UTC (permalink / raw)
  To: Drew DeVault, Lars Ingebrigtsen, Eli Zaretskii
  Cc: theo, Philip Kaludercic, danflscr, monnier, emacs-devel

On 30.08.2021 16:03, Drew DeVault wrote:
> On Mon Aug 30, 2021 at 3:00 PM CEST, Dmitry Gutov wrote:
>> On 30.08.2021 15:49, Drew DeVault wrote:
>>>> Will that affect only replies to later emails?
>>> Yes.
>> I think that can be fixed in the mailing list software layer: if an
>> email is addressed to a thread, and there are some ostensibly
>> "subscribed" users that are missing from the list of recipients, send it
>> to them too.
> Yes, this would work, but only for later emails. I certainly would not
> want to try and apply it retroactively by emailing someone 100 messages
> after they chime in at the end of a large thread.

Sure. That's how "subscribe to a thread" usually works anyway.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* debbugs [was Re: Gitlab Migration]
  2021-08-27 21:07   ` Stefan Monnier
  2021-08-28  2:31     ` Arthur Miller
  2021-08-28  5:57     ` Eli Zaretskii
@ 2021-08-30 15:26     ` Glenn Morris
  2021-08-30 16:09       ` Stefan Monnier
  2 siblings, 1 reply; 525+ messages in thread
From: Glenn Morris @ 2021-08-30 15:26 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel, Daniel Fleischer, Daniel Martín


Obviously no-one's working on d.g.o (for some time), but for the record:

Stefan Monnier wrote:

> - Can't search the database when I'm offline.
>   I really wish the database was stored in Git, so I could easily have
>   a clone of it. 

I can't see how this could have worked in practice, given the size of
the database.

> - No notion of "subscription" to a bug, so replies will sometimes fail
>   to reach me.

A clear shortcoming. I imagine this wouldn't have been too difficult to
implement - just have a flat text file of subscribed addresses for a
report that gets appended to the maintainer list. Ref:
https://debbugs.gnu.org/5439

> - The notion of "archived" bugs is a pain in the rear when you send a
> new message and the message just bounces back with "the bug is
> archived". Either get rid of it, or automatically unarchive bugs when

I think archiving is important for performance reasons.
I imagine automatic unarchiving would have been easy to do, and I agree
it would be useful. Back in the day, I wasn't so sure, eg I thought that
mostly what would happen is that it would mean people could respond to
very old bugs by mistake without noticing.

> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>   I'd like, and maybe some of it can be done via tags and other things
>   already, but I think I'd like it if bugs could be "assigned" to persons
>   and/or to files and/or to "subsystems"

There are the "owner" and "usertag" commands.

> The poor web UI is of course another criticism but it mostly doesn't
> affect me.

The guix people made a wrapper - https://issues.guix.gnu.org/.


Positive feedback back in the day would probably have gotten features 2
and 3 implemented, but the time is long past.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: debbugs.gnu.org search [was gebbugs.gnu.org search]
  2021-08-30 11:42                 ` gebbugs.gnu.org search (was Re: Gitlab Migration) Maxim Nikulin
@ 2021-08-30 15:30                   ` Glenn Morris
  2021-08-31 11:56                     ` debbugs.gnu.org search Maxim Nikulin
  0 siblings, 1 reply; 525+ messages in thread
From: Glenn Morris @ 2021-08-30 15:30 UTC (permalink / raw)
  To: Maxim Nikulin; +Cc: emacs-devel

Maxim Nikulin wrote:

> and links to raw mail messages, e.g. debbugs.gnu.org/db/17/17678.html

At the top of the page, and the bottom, in bold red text, is a link

"Click here to see this page with the latest information and nicer formatting."

For a suggestion for further improvement, see
https://lists.gnu.org/r/help-debbugs/2020-12/msg00026.html


> For this particular query I expect to get
>
>     *#29645 Feature Request: Locale aware formatting*
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645

It's the second result?!

> https://debbugs.gnu.org/robots.txt
>> Disallow: /cgi/

Disallowed due to performance reasons.

The "static" pages are indexed, and contain prominent (though clearly not
prominent enough) links to the "dynamic" pages.


There is also a simple search on https://debbugs.gnu.org/
and a complex one (I agree the interface is weird) on
https://debbugs.gnu.org/cgi/search.cgi



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: debbugs [was Re: Gitlab Migration]
  2021-08-30 15:26     ` debbugs [was Re: Gitlab Migration] Glenn Morris
@ 2021-08-30 16:09       ` Stefan Monnier
  0 siblings, 0 replies; 525+ messages in thread
From: Stefan Monnier @ 2021-08-30 16:09 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Daniel Martín, Daniel Fleischer, emacs-devel

> Obviously no-one's working on d.g.o (for some time), but for the record:

My comments weren't really "requests for improvement" w.r.t
d.g.o, indeed.

>> - Can't search the database when I'm offline.
>>   I really wish the database was stored in Git, so I could easily have
>>   a clone of it. 
> I can't see how this could have worked in practice, given the size of
> the database.

When experimenting with BuGit I created a Git database holding all of
debbugs.gnu.org and that worked fine.  It was a few GBs large,
admittedly, so the concept would require more work to make it
possible/easy to download only a part of the database (the
representation I used does/did make it fairly easy since each issue gets
its own Git branch, the problem is more about the design of a UI and/or
heuristics to decide which issue to download and or to flush).

>> - The notion of "archived" bugs is a pain in the rear when you send a
>> new message and the message just bounces back with "the bug is
>> archived". Either get rid of it, or automatically unarchive bugs when
> I think archiving is important for performance reasons.

I definitely agree that the implementation would want to have a notion
of "active" vs "inactive" issues for performance reasons (e.g. the above
multi-GB Git clone would have shrunk a fair bit if it only included the
non-archived bugs).

> I imagine automatic unarchiving would have been easy to do, and I agree
> it would be useful. Back in the day, I wasn't so sure, eg I thought that
> mostly what would happen is that it would mean people could respond to
> very old bugs by mistake without noticing.

An automatic message in return to the author pointing out that this is
an old bug would do the job for that.  No need to divert the message to
/dev/null.  After all, all the other recipients will have received the
message anyway.

>> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>>   I'd like, and maybe some of it can be done via tags and other things
>>   already, but I think I'd like it if bugs could be "assigned" to persons
>>   and/or to files and/or to "subsystems"
> There are the "owner" and "usertag" commands.

Indeed, the basic functionality is there, but I somehow never got to
using it.  In web UIs these categorization tools tend to be shown in
such a way that I'm encouraged to use them, whereas in debbugs's email
interface I really have to go out of my way to use them.
Not sure how to do better within the scope of an email interface.


        Stefan




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-26 21:52               ` Arthur Miller
@ 2021-08-30 16:30                 ` João Távora
  2021-08-30 16:51                   ` Drew Adams
  2021-08-30 19:18                   ` André A. Gomes
  0 siblings, 2 replies; 525+ messages in thread
From: João Távora @ 2021-08-30 16:30 UTC (permalink / raw)
  To: Arthur Miller
  Cc: Philip K.,
	Daniel Fleischer, emacs-devel, Dmitry Gutov, Lars Ingebrigtsen,
	Eli Zaretskii, Drew Adams

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

On Thu, Aug 26, 2021, 22:53 Arthur Miller <arthur.miller@live.com> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
>
> >>
> > 3. Something else that might help a bit is to include,
> > in each mail sent to a bug thread, a debbugs.gnu.org
> > link to that post.
>
> That sounds like a good idea in my eyes.


Apologies for chiming in late, but this is too interesting of an idea
to let go.

I think adding it to one or two lines in a kind of signature like:

   [[ view full bug history in https://debbugs.gnu.org/.../12345 ]]
   [[ repliers consider keeping these lines ]]

... in the same situations that the subject line is mutated.  Could
be a simple to implement and very useful idea.

João

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* RE: [External] : Re: Gitlab Migration
  2021-08-30 16:30                 ` João Távora
@ 2021-08-30 16:51                   ` Drew Adams
  2021-08-30 17:59                     ` João Távora
  2021-08-30 19:18                   ` André A. Gomes
  1 sibling, 1 reply; 525+ messages in thread
From: Drew Adams @ 2021-08-30 16:51 UTC (permalink / raw)
  To: João Távora, Arthur Miller
  Cc: Philip K.,
	Daniel Fleischer, emacs-devel, Dmitry Gutov, Eli Zaretskii,
	Lars Ingebrigtsen

> I think adding it to one or two lines in a kind of signature like:
>
>  [[ view full bug history in https://debbugs.gnu.org/.../12345]]
>  [[ repliers consider keeping these lines ]]
>
> ... in the same situations that the subject line is mutated.
> Could be a simple to implement and very useful idea.

The link would be to the specific post within the
bug thread.  So instead of "view full bug history"
I'd suggest something like "View in bug thread"
or "view in context" (or "full history" instead
of "thread" or "context").

It's about viewing the particular post, but within
the full thread.

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: SourceHut for Emacs (was: Gitlab Migration)
  2021-08-28 13:04         ` SourceHut for Emacs (was: Gitlab Migration) Stefan Monnier
@ 2021-08-30 17:59           ` Sean Whitton
  2021-08-30 20:17           ` Yuan Fu
  1 sibling, 0 replies; 525+ messages in thread
From: Sean Whitton @ 2021-08-30 17:59 UTC (permalink / raw)
  To: Stefan Monnier, emacs-devel

Hello,

On Sat 28 Aug 2021 at 09:04AM -04, Stefan Monnier wrote:

> Reading this discussion made me realize why I'm rooting for SourceHut:
> it's the only such tool I've seen whose goals align exactly with ours.
> Both philosophically (most other tools just happen to be Free Software
> and but are more philosophically aligned with Open Source) and
> technically (it aims for first class email support while providing as
> much as possible of the shiny web features of other systems).
>
> So at this stage, I personally don't see much point looking for other
> tools.  Instead I'm just wondering how to get us to use SourceHut
> (i.e. how to resolve the problems that might stand in the way, such as
> getting an instance up and running on GNU machines, starting to use it
> "on the side" to see in practice what issues we'll need
> fixed/improved/added before we can really switch, etc...).

Perhaps we could get a GNU-hosted instance stood up to play with?

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-30 16:51                   ` Drew Adams
@ 2021-08-30 17:59                     ` João Távora
  0 siblings, 0 replies; 525+ messages in thread
From: João Távora @ 2021-08-30 17:59 UTC (permalink / raw)
  To: Drew Adams, Lars Ingebrigtsen
  Cc: Philip K.,
	Daniel Fleischer, emacs-devel, Arthur Miller, Dmitry Gutov,
	Eli Zaretskii

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

On Mon, Aug 30, 2021, 17:51 Drew Adams <drew.adams@oracle.com> wrote:

> > I think adding it to one or two lines in a kind of signature like:
> >
> >  [[ view full bug history in https://debbugs.gnu.org/.../12345]]
> >  [[ repliers consider keeping these lines ]]
> >
> > ... in the same situations that the subject line is mutated.
> > Could be a simple to implement and very useful idea.
>
> The link would be to the specific post within the
> bug thread.  So instead of "view full bug history"
> I'd suggest something like "View in bug thread"
> or "view in context" (or "full history" instead
> of "thread" or "context").
>
> It's about viewing the particular post, but within
> the full thread.
>

Fine.

Who could make this happen? Lars?

João

>

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: [External] : Re: Gitlab Migration
  2021-08-30 16:30                 ` João Távora
  2021-08-30 16:51                   ` Drew Adams
@ 2021-08-30 19:18                   ` André A. Gomes
  1 sibling, 0 replies; 525+ messages in thread
From: André A. Gomes @ 2021-08-30 19:18 UTC (permalink / raw)
  To: João Távora
  Cc: Philip K.,
	Daniel Fleischer, emacs-devel, Arthur Miller, Dmitry Gutov,
	Lars Ingebrigtsen, Eli Zaretskii, Drew Adams

João Távora <joaotavora@gmail.com> writes:

> On Thu, Aug 26, 2021, 22:53 Arthur Miller <arthur.miller@live.com>
> wrote:
>
>     Drew Adams <drew.adams@oracle.com> writes:
>
>     >>
>     > 3. Something else that might help a bit is to include,
>     > in each mail sent to a bug thread, a debbugs.gnu.org
>     > link to that post.
>
>     That sounds like a good idea in my eyes.
>
> Apologies for chiming in late, but this is too interesting of an idea
> to let go.

If my understanding of this thread is correct, this is exactly what
happens when you submit a bug report in GNU Guix.

Not only it's doable, but it's already written somewhere :)


--
André A. Gomes
"Free Thought, Free World"



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: SourceHut for Emacs (was: Gitlab Migration)
  2021-08-28 13:04         ` SourceHut for Emacs (was: Gitlab Migration) Stefan Monnier
  2021-08-30 17:59           ` Sean Whitton
@ 2021-08-30 20:17           ` Yuan Fu
  2021-08-31 12:03             ` Eli Zaretskii
  1 sibling, 1 reply; 525+ messages in thread
From: Yuan Fu @ 2021-08-30 20:17 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel



> On Aug 28, 2021, at 6:04 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> Reading this discussion made me realize why I'm rooting for SourceHut:
> it's the only such tool I've seen whose goals align exactly with ours.
> Both philosophically (most other tools just happen to be Free Software
> and but are more philosophically aligned with Open Source) and
> technically (it aims for first class email support while providing as
> much as possible of the shiny web features of other systems).

Completely agree.

> 
> So at this stage, I personally don't see much point looking for other
> tools.  Instead I'm just wondering how to get us to use SourceHut
> (i.e. how to resolve the problems that might stand in the way, such as
> getting an instance up and running on GNU machines, starting to use it
> "on the side" to see in practice what issues we'll need
> fixed/improved/added before we can really switch, etc...).
> 
> An obvious first issue is the one seen in Theodor's example:
> https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
> where the rendering of this email in the web interface completely hides
> the actual patch being sent.
> 

Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.

Yuan


^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: rmail threading
  2021-08-30 12:07                         ` Eli Zaretskii
@ 2021-08-31  3:09                           ` Richard Stallman
  2021-08-31 12:47                             ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-31  3:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: tomas, emacs-devel

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

  > I prefer not to review a thread via a summary, because a specialized
  > summary prevents me from easily seeing messages that don't satisfy the
  > summary criteria.

I am not sure what this means.  A summary based on filtering will show
some messages and not others, but how is that harmful?
It sounds like you want two conflicting things -- what two things are they?

Could you say concretely what "prevents..,from easily seeing" means?
A summary in Rmail doesn't stop you from looking at messages not
included in it.  I do that frequently.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 12:20                 ` Dmitry Gutov
  2021-08-30 12:48                   ` Daniel Fleischer
@ 2021-08-31  3:09                   ` Richard Stallman
  2021-08-31 11:43                     ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-08-31  3:09 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: eliz, danflscr, philipk, monnier, emacs-devel

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

  > Yes, as is now apparent from multiple arguments around the subject, 
  > appealing to newcomers (and/or trying to adopt contemporary usability 
  > practices) is of much lesser priority than, say, making sure that each 
  > key binding that has been with us for a number of years, is left 
  > unchanged for ever. We hate to risk inconveniencing existing users.

Please don't bring sarcasm into our discussions.  It tends to make the
discussion more acrimonious and make agreement more difficult.
Any point can be made without sarcasm, and it's likely to arouse
less resistance that way.

See https://gnu.org/philosophy/kind-communication.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)





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31  3:09                   ` Richard Stallman
@ 2021-08-31 11:43                     ` Dmitry Gutov
  2021-08-31 16:03                       ` João Távora
                                         ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-31 11:43 UTC (permalink / raw)
  To: rms; +Cc: eliz, danflscr, philipk, monnier, emacs-devel

On 31.08.2021 06:09, Richard Stallman wrote:
>    > Yes, as is now apparent from multiple arguments around the subject,
>    > appealing to newcomers (and/or trying to adopt contemporary usability
>    > practices) is of much lesser priority than, say, making sure that each
>    > key binding that has been with us for a number of years, is left
>    > unchanged for ever. We hate to risk inconveniencing existing users.
> 
> Please don't bring sarcasm into our discussions.  It tends to make the
> discussion more acrimonious and make agreement more difficult.
> Any point can be made without sarcasm, and it's likely to arouse
> less resistance that way.

I wasn't really that sarcastic. The above is literally my observations 
on our decision-making in the area.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: debbugs.gnu.org search
  2021-08-30 15:30                   ` debbugs.gnu.org search [was gebbugs.gnu.org search] Glenn Morris
@ 2021-08-31 11:56                     ` Maxim Nikulin
  0 siblings, 0 replies; 525+ messages in thread
From: Maxim Nikulin @ 2021-08-31 11:56 UTC (permalink / raw)
  To: emacs-devel

On 30/08/2021 22:30, Glenn Morris wrote:
> Maxim Nikulin wrote:
>> and links to raw mail messages, e.g. debbugs.gnu.org/db/17/17678.html
> 
> At the top of the page, and the bottom, in bold red text, is a link
> "Click here to see this page with the latest information and nicer formatting."

Thank you, I have not noticed this link. I believed that link to raw 
messages were indexed by mistake instead of regular pages. My 
expectations were based on what I saw in bug reports on bugs.debian.org. 
My point is that it is still inconvenient to both humans (intermediate 
page) and search engines (heuristics is not powerful enough to recognize 
valuable parts).

> For a suggestion for further improvement, see
> https://lists.gnu.org/r/help-debbugs/2020-12/msg00026.html

Though this branch of "mail vs. web UI" discussion of communication with 
users and contributors is rather off-topic, it seems, the link you 
provided, might explain why some part of users prefer web UI for 
interaction. Technical details of communication are not available to 
crawlers (e.g. forensic ones, unfortunately been still fully available 
to site owners though). Alternative variant of your link:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43073
"#43073 Trim/hide full email headers on debbugs"

>> For this particular query I expect to get
>>
>>      *#29645 Feature Request: Locale aware formatting*
>>      https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645
> 
> It's the second result?!

Glad to see that the recipe works for someone. I am not so lucky. See 
below for details.

>> https://debbugs.gnu.org/robots.txt
>>> Disallow: /cgi/
> 
> Disallowed due to performance reasons.
> 
> The "static" pages are indexed, and contain prominent (though clearly not
> prominent enough) links to the "dynamic" pages.

I suspected that indexing was broken intentionally. However static pages 
may still be better formatted in my opinion (and with a footer with 
prominent last update time to avoid confusion related to recent updates).

I have not noticed any special HTTP header sent by bugs.debian.org that 
my alleviate server load during scan by search engines. Unsure that 
"cache-control: public, max-age=600" plays a significant role.

> There is also a simple search on https://debbugs.gnu.org/
> and a complex one (I agree the interface is weird) on
> https://debbugs.gnu.org/cgi/search.cgi

I intentionally preserved the following in my previous message.

>>> 5. And debbugs.gnu.org search sucks.  Or at least I suck
>>> at trying to find anything using it.

My impression is that "general purpose" search engines are usually able 
to provide more relevant results due to handling of common typos, 
synonyms, etc. At least while there are no precise criteria for a filter...

So the problem is not really reproducible, thus harder to debug. Namely 
duckduckgo does not show #29645 for me on the first page at all. Maybe 
it depends on region from which a request is originated.

There is another issue with "static" debbugs pages for indexing by 
search engines: poor metadata. HTML TITLE element contains just "GNU bug 
report logs - #29645". Debbugs does not support '<meta 
name="description" content="">' and similar info.

+ duckduckgo (unsure concerning particular underlying engine in my case,
   maybe bing):
   - no #29645 in results
   - title is not informative: "GNU bug report logs - #27544"
   - summary is either enumeration of headers or a part of message
     body. In the former case it is impossible to estimate relevance
     of particular result.
 
https://html.duckduckgo.com/html?q=site%3Adebbugs.gnu.org+emacs+locale+number
+ google
   - title often (but not always) is taken from H1 element,
     so it is usually much better
     "GNU bug report logs - #29645 Feature Request: Locale aware ..."
     Unfortunately it is trimmed.
   - summary: often useless raw headers
     "... X-Spam-Status: No, score=0.8 required=5.0 
tests=BAYES_50,FREEMAIL_FROM, ... Request: Locale aware formatting To: 
bug-gnu-emacs@HIDDEN Content-Type: ..."
 
https://www.google.com/search?q=site%3Adebbugs.gnu.org+emacs+locale+number
+ yandex
   - #29645 sometimes is present, sometimes it is not
   - title is useless: "GNU bug report logs - #29645"
   - summary: a snippet from report is hardly noticeable since
     bug status is placed earlier
     "Package: emacs; Severity: wishlist; Reported by: Gustaf
     Waldemarson ... A while ago I started looking for some simple way
     of writing numbers correctly formatted to the locale. Specifically,
     I wanted the output to use the locale's..."
     It may be completely useless though:
     "Package: emacs; Reported by: Jan Synacek <jsynacek@HIDDEN>;
     merged with #3219 ... Information forwarded to bug-gnu-emacs@HIDDEN:
     bug#40007; Package emacs. Full text available. Merged 3219 4123 9589
     13675 15555..."
   https://yandex.ru/search/?text=site%3Adebbugs.gnu.org+emacs+locale+number
+ bing
   - no #29645
   - titles are useless: "GNU bug report logs - #5618"
   - summary varies from message body snippets to just
     "information forwarded to bug-gnu-emacs@HIDDEN: bug#3229; Package 
emacs. Full text available"
   https://www.bing.com/search?q=site%3Adebbugs.gnu.org+emacs+locale+number

My conclusion is that debbugs.gnu.org is not friendly to search engines, 
so relevant results are not guaranteed, it is hard to estimate if 
particular item may be useful looking at its title and summary. It does 
not matter whether DebBugs, GitLab, or SourceHut is used as a bug 
tracker if robots.txt file does not allow to index descriptions friendly 
to users and to search engines.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: SourceHut for Emacs (was: Gitlab Migration)
  2021-08-30 20:17           ` Yuan Fu
@ 2021-08-31 12:03             ` Eli Zaretskii
  2021-09-01 22:40               ` Yuan Fu
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-31 12:03 UTC (permalink / raw)
  To: Yuan Fu; +Cc: monnier, emacs-devel

> From: Yuan Fu <casouri@gmail.com>
> Date: Mon, 30 Aug 2021 13:17:42 -0700
> Cc: emacs-devel@gnu.org
> 
> > So at this stage, I personally don't see much point looking for other
> > tools.  Instead I'm just wondering how to get us to use SourceHut
> > (i.e. how to resolve the problems that might stand in the way, such as
> > getting an instance up and running on GNU machines, starting to use it
> > "on the side" to see in practice what issues we'll need
> > fixed/improved/added before we can really switch, etc...).
> > 
> > An obvious first issue is the one seen in Theodor's example:
> > https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
> > where the rendering of this email in the web interface completely hides
> > the actual patch being sent.
> > 
> 
> Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.

They are already participating in these discussions here.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: rmail threading
  2021-08-31  3:09                           ` Richard Stallman
@ 2021-08-31 12:47                             ` Eli Zaretskii
  2021-09-02  3:37                               ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-31 12:47 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Mon, 30 Aug 2021 23:09:24 -0400
> 
>   > I prefer not to review a thread via a summary, because a specialized
>   > summary prevents me from easily seeing messages that don't satisfy the
>   > summary criteria.
> 
> I am not sure what this means.  A summary based on filtering will show
> some messages and not others, but how is that harmful?
> It sounds like you want two conflicting things -- what two things are they?
> 
> Could you say concretely what "prevents..,from easily seeing" means?

Once you request a summary based on filtering, the unfiltered summary
is gone.  So I can no longer quickly and conveniently look for
messages that were filtered out by scrolling the summary buffer or by
searching in it.

Suppose a message in a thread changed the subject, enough so that
neither summary by subject nor rmail-next-same-subject find it.  With
the unfiltered summary buffer, I can still look for it, e.g. by
searching for the sender or some fragment of the Subject in the
summary buffer.  With summary-by-topic, I can't do that.

> A summary in Rmail doesn't stop you from looking at messages not
> included in it.  I do that frequently.

Can you tell how do you do that?

And I have one additional question about your request to have a
summary-by-thread: is it okay to request that the user first sorts the
messages by date (C-c C-s C-d), before summarizing the thread?  If
not, then the implementation should be much more complicated, and the
resulting order of the messages in the summary could be confusing,
because messages could have arrived out of order, which happens when,
for example, the email server was temporarily off-line.  If the
messages are sorted by date/time, the order will be reasonable
(barring clock mismatches).



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 11:43                     ` Dmitry Gutov
@ 2021-08-31 16:03                       ` João Távora
  2021-08-31 16:15                         ` Clément Pit-Claudel
                                           ` (2 more replies)
  2021-08-31 16:21                       ` John Yates
  2021-09-02  3:37                       ` Richard Stallman
  2 siblings, 3 replies; 525+ messages in thread
From: João Távora @ 2021-08-31 16:03 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Eli Zaretskii

On Tue, Aug 31, 2021 at 12:50 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 31.08.2021 06:09, Richard Stallman wrote:
> >    > Yes, as is now apparent from multiple arguments around the subject,
> >    > appealing to newcomers (and/or trying to adopt contemporary usability
> >    > practices) is of much lesser priority than, say, making sure that each
> >    > key binding that has been with us for a number of years, is left
> >    > unchanged for ever. We hate to risk inconveniencing existing users.
> >
> > Please don't bring sarcasm into our discussions.  It tends to make the
> > discussion more acrimonious and make agreement more difficult.
> > Any point can be made without sarcasm, and it's likely to arouse
> > less resistance that way.
>
> I wasn't really that sarcastic. The above is literally my observations
> on our decision-making in the area.

I want to offer a small amount of anecdotal evidence in favor of the
recent push to Sourcehut and against the GitLab/GitHub alternatives
that are presumably favoured by you (Dmitry) and some others.  In recent
$DAYJOBs I worked with these two GL/GH platforms fully, using them
liberally and without restrictions. In these recent experiences the undeniable
contemporarity and newcomer friendliness of these platforms does NOT
seem to translate into quality of code, quality of discussion or any
kind of benefic developer agility in any way.  Again, just anecdotal
evidence which you may take for what it's worth, but in fact I believe
that the "slow", unfamiliar, peculiar, old-school whatever-you-want-to-call-them
methods used in Emacs development may in fact be "aces up our
sleeve", not just a means to appease those that have been using them
for a number of years.

João



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:03                       ` João Távora
@ 2021-08-31 16:15                         ` Clément Pit-Claudel
  2021-08-31 16:39                           ` João Távora
  2021-08-31 18:53                         ` André A. Gomes
  2021-08-31 19:33                         ` Dmitry Gutov
  2 siblings, 1 reply; 525+ messages in thread
From: Clément Pit-Claudel @ 2021-08-31 16:15 UTC (permalink / raw)
  To: emacs-devel

On 8/31/21 12:03 PM, João Távora wrote:
> gain, just anecdotal evidence which you may take for what it's worth,
> but in fact I believe that the "slow", unfamiliar, peculiar,
> old-school whatever-you-want-to-call-them methods used in Emacs
> development may in fact be "aces up our sleeve", not just a means to
> appease those that have been using them for a number of years.

I had a different experience: a large project I contribute to occasionally (Coq) moved to Github a few years ago, and that was followed with a significant increase in first-time contributions.

On a smaller scale, we have had many more (good) bug reports and pull requests for Proof General since we moved it to Github.

What this doesn't say is whether any "modern" workflow would have helped, or whether it was specifically Github, because of network effects (the barrier for contribution is lower if you already have an account and you are already familiar with the UI).

In fact, it doesn't even say whether it was the move itself that helped, or whether the move was an irrelevant manifestation of a more welcoming approach and a general effort to attract contributions.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 11:43                     ` Dmitry Gutov
  2021-08-31 16:03                       ` João Távora
@ 2021-08-31 16:21                       ` John Yates
  2021-08-31 16:37                         ` Eli Zaretskii
  2021-09-03  3:09                         ` Richard Stallman
  2021-09-02  3:37                       ` Richard Stallman
  2 siblings, 2 replies; 525+ messages in thread
From: John Yates @ 2021-08-31 16:21 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Philip Kaludercic, danflscr, Richard Stallman, Emacs developers,
	Stefan Monnier, Eli Zaretskii

On Tue, Aug 31, 2021 at 7:50 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> appealing to newcomers (and/or trying to adopt contemporary usability
> practices) is of much lesser priority than, say, making sure that each
> key binding that has been with us for a number of years, is left
> unchanged for ever. We hate to risk inconveniencing existing users.

I agree with Dmitry.  I would love to see the community be
more open to change, be it key bindings or new workflows.

I have been using Emacs since Lucid-Emacs at Apollo
Computer in the mid-1980s.  I have a massive .init file.
Still, I welcome change and evolution.  Other technologies
that I use on a daily basis evolve, even those for which I
develop muscle memory (e.g. my smart phone).  I accept
such change and can even acknowledge that some of it
represents progress over time.  Other changes I put up
with just to track the herd and not be left behind.

I wish that we were not so determined to proudly go it alone.
Our stances often remind me of this ditty:

    Here lies the body of William Jay,
    who died maintaining his right of way.
    He was right as he sped along—
    but he's just as dead as if he'd been wrong.

Any changes that can attract new blood have my vote.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:21                       ` John Yates
@ 2021-08-31 16:37                         ` Eli Zaretskii
  2021-08-31 19:17                           ` Dmitry Gutov
  2021-09-03  3:09                         ` Richard Stallman
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-31 16:37 UTC (permalink / raw)
  To: John Yates; +Cc: philipk, danflscr, rms, emacs-devel, monnier, dgutov

> From: John Yates <john@yates-sheets.org>
> Date: Tue, 31 Aug 2021 12:21:40 -0400
> Cc: Richard Stallman <rms@gnu.org>, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com, 
> 	Philip Kaludercic <philipk@posteo.net>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I have been using Emacs since Lucid-Emacs at Apollo
> Computer in the mid-1980s.  I have a massive .init file.
> Still, I welcome change and evolution.  Other technologies
> that I use on a daily basis evolve, even those for which I
> develop muscle memory (e.g. my smart phone).  I accept
> such change and can even acknowledge that some of it
> represents progress over time.  Other changes I put up
> with just to track the herd and not be left behind.
> 
> I wish that we were not so determined to proudly go it alone.

Please don't exaggerate.  Representing Emacs development as something
that didn't change since the 1980s is factually incorrect and
practically not helpful.

> Any changes that can attract new blood have my vote.

Everyone agrees with general principles, the disagreements begin when
we consider the details.  E.g., "any changes" is definitely a
generalization that is not very useful in practice.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:15                         ` Clément Pit-Claudel
@ 2021-08-31 16:39                           ` João Távora
  0 siblings, 0 replies; 525+ messages in thread
From: João Távora @ 2021-08-31 16:39 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

On Tue, Aug 31, 2021 at 5:15 PM Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:
>
> On 8/31/21 12:03 PM, João Távora wrote:
> > gain, just anecdotal evidence which you may take for what it's worth,
> > but in fact I believe that the "slow", unfamiliar, peculiar,
> > old-school whatever-you-want-to-call-them methods used in Emacs
> > development may in fact be "aces up our sleeve", not just a means to
> > appease those that have been using them for a number of years.
>
> I had a different experience: a large project I contribute to occasionally (Coq) moved to Github a few years ago, and that was followed with a significant increase in first-time contributions.
>
> On a smaller scale, we have had many more (good) bug reports and pull requests for Proof General since we moved it to Github.
>
> What this doesn't say is whether any "modern" workflow would have helped, or whether it was specifically Github, because of network effects (the barrier for contribution is lower if you already have an account and you are already familiar with the UI).
>
> In fact, it doesn't even say whether it was the move itself that helped, or whether the move was an irrelevant manifestation of a more welcoming approach and a general effort to attract contributions.

Yes, something very similar happened when I and a colleague moved
SLIME to GitHub
around 2014, when it was almost moribund. It revitalized the project
in a way, i.e.
it increased the number of bug reports that were effectively reported,
but it didn't really
bring momentous changes or advances to the software  (I ended up doing
those in a
fork of it, which is now SLY).  It's certainly better there than in
the those moribund
Common Lisp venues and CVS.

I think you make good points, anyway.

João



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:03                       ` João Távora
  2021-08-31 16:15                         ` Clément Pit-Claudel
@ 2021-08-31 18:53                         ` André A. Gomes
  2021-09-04 23:45                           ` Yuchen Pei
  2021-08-31 19:33                         ` Dmitry Gutov
  2 siblings, 1 reply; 525+ messages in thread
From: André A. Gomes @ 2021-08-31 18:53 UTC (permalink / raw)
  To: João Távora
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Dmitry Gutov, Eli Zaretskii

João Távora <joaotavora@gmail.com> writes:

> [...] but in fact I believe that the "slow", unfamiliar, peculiar,
> old-school whatever-you-want-to-call-them methods used in Emacs
> development may in fact be "aces up our sleeve", not just a means to
> appease those that have been using them for a number of years.

I couldn't agree more.  There are historical (and technical) reasons for
the Emacs development being the way it is.  From my point of view, the
point of view of an enthusiast and absolute beginner, I've matured
respect and appreciation for the modus operandi of this community.  I
acknowledge that "easy" options are often illusions.

I don't think Emacs cultivates "elitism".  But it does require
proficiency, which is only sensible.  If getting more people on board
entails lowering the bar, then Emacs would be subscribing to "worse is
better".  Emacs doesn't stand for that, and it's not on a race.


--
André A. Gomes
"Free Thought, Free World"



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:37                         ` Eli Zaretskii
@ 2021-08-31 19:17                           ` Dmitry Gutov
  2021-08-31 19:37                             ` Eli Zaretskii
  2021-08-31 22:24                             ` John Yates
  0 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-31 19:17 UTC (permalink / raw)
  To: Eli Zaretskii, John Yates; +Cc: philipk, emacs-devel, danflscr, rms, monnier

On 31.08.2021 19:37, Eli Zaretskii wrote:

>> Any changes that can attract new blood have my vote.
> 
> Everyone agrees with general principles,

With "any changes that can attract new blood", really?

> the disagreements begin when
> we consider the details.  E.g., "any changes" is definitely a
> generalization that is not very useful in practice.

FWIW, I mentioned particular categories of changes.

Or as I've been saying, we love additions but hate changes. This is a 
distinction that's easy to conceptualize, and we could start a 
discussion into changing this, or at least instituting some procedures 
for making important non-backward-compatible changes. Nobody with power 
to make decisions has shown any interest, however.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:03                       ` João Távora
  2021-08-31 16:15                         ` Clément Pit-Claudel
  2021-08-31 18:53                         ` André A. Gomes
@ 2021-08-31 19:33                         ` Dmitry Gutov
  2021-08-31 22:25                           ` João Távora
  2021-09-03  3:10                           ` Richard Stallman
  2 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-08-31 19:33 UTC (permalink / raw)
  To: João Távora
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Eli Zaretskii

On 31.08.2021 19:03, João Távora wrote:
> I want to offer a small amount of anecdotal evidence in favor of the
> recent push to Sourcehut and against the GitLab/GitHub alternatives
> that are presumably favoured by you (Dmitry) and some others.

FWIW, I'm really more interested in UI changes than workflow changes (my 
email mentioned both). A move that will at least bring us a functioning 
bug tracker is a plus in my book.

> In recent
> $DAYJOBs I worked with these two GL/GH platforms fully, using them
> liberally and without restrictions. In these recent experiences the undeniable
> contemporarity and newcomer friendliness of these platforms does NOT
> seem to translate into quality of code, quality of discussion or any
> kind of benefic developer agility in any way.

That's an odd statement. First of all, why would quality of code change? 
Whatever linters you institute to run on a CI, can run locally as well. 
Quality of discussions is also on you.

gitlab/github/gogs/etc give you tools to make code reviews easier, and 
an opportunity to attract many new contributors, but then it's on you to 
make them feel welcome, so that they stay around.

Better "quality of code" can result from attracting strong new 
contributors, and looking at how, for example, bug#47711 ended up (a 
smart, prolific developer who has authored a number of popular 
third-party packages in the same area has now sworn off contributing to 
Emacs), or the atmosphere around Eglot, I find it hard to trust your 
experience here.

> Again, just anecdotal
> evidence which you may take for what it's worth, but in fact I believe
> that the "slow", unfamiliar, peculiar, old-school whatever-you-want-to-call-them
> methods used in Emacs development may in fact be "aces up our
> sleeve", not just a means to appease those that have been using them
> for a number of years.

Sure, let's keep the barriers to contribution, both formal and informal 
ones. That will serve us well.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 19:17                           ` Dmitry Gutov
@ 2021-08-31 19:37                             ` Eli Zaretskii
  2021-09-01 11:35                               ` John Yates
  2021-08-31 22:24                             ` John Yates
  1 sibling, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-08-31 19:37 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

> Cc: rms@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 31 Aug 2021 22:17:10 +0300
> 
> Or as I've been saying, we love additions but hate changes.

Emacs is an old and _stable_ package.  "Stable" means just that:
features burned into users' muscle memory don't just change every
weekend.  So we do it slowly, cautiously, and preferably via opt-in
features, because we respect our users and their habits.  It is
maddening to have to re-learn your editor just because you've
upgraded.

> we could start a discussion into changing this, or at least
> instituting some procedures for making important
> non-backward-compatible changes.

We _have_ procedures for making backward-incompatible changes, and we
use those procedures all the time.

> Nobody with power to make decisions has shown any interest, however.

Please forgive me the lecture that you don't need: talking never moves
anything in Emacs, never did, never will.  Change in Emacs comes when
motivated individuals sit down and do the work.  If someone presents
the code to make some backward-incompatible change in a way that
leaves it opt-in, the resistance is likely to be much lower than it
may seem when such changes are just "discussed".  For the same reason,
it is hard to show interest in an Nth theoretical discussion that
never results in any code; by contrast, having a code presented to us
_requires_ "The Powers That Be" to make decisions, whether they want
it or not.

Backward-incompatible changes in the _defaults_ take much longer and
might be met with more resistance, that's true.  But this is a feature
in Emacs; see above.  My advice is not to insist on having each
incompatible change to become the default the moment it is coded: it
will in the long run make such changes much easier to introduce, and
everyone wins.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 19:17                           ` Dmitry Gutov
  2021-08-31 19:37                             ` Eli Zaretskii
@ 2021-08-31 22:24                             ` John Yates
  1 sibling, 0 replies; 525+ messages in thread
From: John Yates @ 2021-08-31 22:24 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Philip Kaludercic, danflscr, Richard Stallman, Emacs developers,
	Stefan Monnier, Eli Zaretskii

On Tue, Aug 31, 2021 at 3:17 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> With "any changes that can attract new blood", really?

Sure.  Mine is not the only vote and carries much less
weight than some.  But, as a first approximation, any
serious proposal that would "attract new blood" almost
surely, has my support.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 19:33                         ` Dmitry Gutov
@ 2021-08-31 22:25                           ` João Távora
  2021-09-03  3:10                           ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: João Távora @ 2021-08-31 22:25 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Eli Zaretskii

Dmitry Gutov <dgutov@yandex.ru> writes:

> A move that will at least bring us a functioning bug tracker is a plus
> in my book.

We are in agreement. 

> That's an odd statement. First of all, why would quality of code
> change? Whatever linters you institute to run on a CI, can run locally
> as well. Quality of discussions is also on you.
>
> gitlab/github/gogs/etc give you tools to make code reviews easier, and
> an opportunity to attract many new contributors, but then it's on you
> to make them feel welcome, so that they stay around.

I'm telling you that code reviews and the ensuing code quality didn't
become specially easier when comparing GH/GL to non-GH/GL.  There were
code reviews with and without these platforms and there were newcomers
with and without them.  There was no perceptual (from my POV) difference
in discussion or proficiency.  This was presented as anecdoctal evidence
and my subjective judgement, of course.  If it sounds "odd" to you, it's
totally understandable.

> Better "quality of code" can result from attracting strong new
> contributors, and looking at how, for example, bug#47711 ended up (a
> smart, prolific developer who has authored a number of popular
> third-party packages in the same area has now sworn off contributing
> to Emacs),

Shooting from the hip, heh :-) Well, if you are so troubled by bug#47711
I encourage you to reply there.  Not only am I waiting your promised
feedback but also it's got absolutely nothing do to with this
thread. (IIUC the participants in that bug are familiar and proficient
with Emacs's workflows and practices).

Bugs don't have to "end up" anywhere without discussion, opposition or
study of alternatives: Daniel wants to deprecate a part of Emacs and
substitute it with a new one.  To my eyes, that's a good idea.  I merely
had time and means to demonstrate that his patch made Icomplete run
about 10% slower.  He later thanked me for spotting this regression.  I
also asked to split up the patch, which is very long and seemed to do
many things at once, so that I could more easily review it.  After
providing an alternative patch, I'm waiting from you and Daniel a
translucid demonstration of the somewhat callous claims leveled at it.
It's short and speeds up icomplete-mode and flex by about 30%, as
requested by none other than you.  Indeed, I have been waiting for these
things and other things for about 2 weeks, and haven't heard a peep.

> or the atmosphere around Eglot, I find it hard to trust your
> experience here.

Intrigued about the amospheric conditions around Eglot.  Should I bring
umbrella or sunscreen?

>> methods used in Emacs development may in fact be "aces up our
>> sleeve", not just a means to appease those that have been using them
>> for a number of years.
> Sure, let's keep the barriers to contribution, both formal and
> informal ones. That will serve us well.

I'll just make one last effort to explain my position here.  You may
legitimately think they e-mail, debbugs, non-modern websites etc are
barriers, that they are "bad" to newcomers.  That is true, and I agree
in part, but it is not the whole story.  Some of us are trying to tell
you that that manichaeism is an oversimplification: these things are
_also_ "good", they are points of interest and value to veterans and at
least a certain class of newcomers, perhaps the newcomers that Emacs is
interested in attracting.

It goes both ways, too: I was once a newcomer and the development
practices that I've learned (and still learn) here specifically over the
years have been very valuable in my programming career.  Just some
examples: the deft use of boring old email to structure programming
ideas is very very good here.  The much-ridiculed GNU-style ChangeLog
commit messages are a superb way to review one's own work before
presenting it.  And I don't miss emojis, thumbsup likes and animated
gifs a bit, have to say.

João



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 19:37                             ` Eli Zaretskii
@ 2021-09-01 11:35                               ` John Yates
  2021-09-01 12:36                                 ` Eli Zaretskii
  2021-09-02  3:38                                 ` Richard Stallman
  0 siblings, 2 replies; 525+ messages in thread
From: John Yates @ 2021-09-01 11:35 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Philip Kaludercic, danflscr, Richard Stallman, Emacs developers,
	Stefan Monnier, Dmitry Gutov

On Tue, Aug 31, 2021 at 3:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Emacs is an old and _stable_ package.  "Stable" means just that:
> features burned into users' muscle memory don't just change every
> weekend.

At 70, I still count myself as an "early adopter".  I am unlikely to
accept having my world and habits disrupted every weekend.  But
with somewhat longer time scales (e.g. Ubuntu's six month and
Android yearly cadences) I am quite comfortable.

> So we do it slowly, cautiously, and preferably via opt-in
> features, because we respect our users and their habits.

Ah, but the model is opt-in to change, not opt-out.  Thus
opponents of change start off with an advantage and set
the terms of debate.

Other models are possible:
* Long term releases with sunset dates
* Previews of features that will become defaults with opt-out
* ?

Anyway, thank you, Eli, for your long, thoughtful reply and
for your project leadership.

/john



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-01 11:35                               ` John Yates
@ 2021-09-01 12:36                                 ` Eli Zaretskii
  2021-09-02  3:38                                 ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-01 12:36 UTC (permalink / raw)
  To: John Yates; +Cc: philipk, danflscr, rms, emacs-devel, monnier, dgutov

> From: John Yates <john@yates-sheets.org>
> Date: Wed, 1 Sep 2021 07:35:10 -0400
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Richard Stallman <rms@gnu.org>, danflscr@gmail.com, 
> 	Philip Kaludercic <philipk@posteo.net>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > Emacs is an old and _stable_ package.  "Stable" means just that:
> > features burned into users' muscle memory don't just change every
> > weekend.
> 
> At 70, I still count myself as an "early adopter".  I am unlikely to
> accept having my world and habits disrupted every weekend.  But
> with somewhat longer time scales (e.g. Ubuntu's six month and
> Android yearly cadences) I am quite comfortable.

How long is "somewhat longer" is obviously very personal and differs
between people.  I've met people for whom 6 months is a blink of an
eye.

> > So we do it slowly, cautiously, and preferably via opt-in
> > features, because we respect our users and their habits.
> 
> Ah, but the model is opt-in to change, not opt-out.  Thus
> opponents of change start off with an advantage and set
> the terms of debate.

I said "preferably opt-in".  We do make opt-out changes as well, just
less so, for the reasons I tried to explain.

> Other models are possible:
> * Long term releases with sunset dates
> * Previews of features that will become defaults with opt-out
> * ?

Someone™ should step forward and volunteer to manage such models.  If
and when they do, I don't see why not, at least not in principle.

> Anyway, thank you, Eli, for your long, thoughtful reply and
> for your project leadership.

You are welcome.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-27  1:01       ` Tim Cross
  2021-08-27  7:07         ` Daniel Fleischer
@ 2021-09-01 17:15         ` Maxim Nikulin
  1 sibling, 0 replies; 525+ messages in thread
From: Maxim Nikulin @ 2021-09-01 17:15 UTC (permalink / raw)
  To: emacs-devel

On 27/08/2021 08:01, Tim Cross wrote:
> Dmitry Gutov writes:
> 
>> Email is used by virtually everyone (for example, to receive notifications about
>> others' actions or messages), what's "unusual" for many is sending patches over
>> email. Or inlining them in comments/messages.
> 
> I'm not sure this is true. I think virtually all developers are forced
> to suffer email, but a gorwing number don't use it. Often, all the
> discussions, notifications, comments etc are actually consumed via a
> mobile 'app'. For these users, logging into their inbox is frustrating
> and inconvenient because their inbox is full of pointless and old
> messages/notifications/alerts they have already seen/received via other
> channels.

Duplication of notifications to a messenger + mail is definitly a source 
of annoyance and ability to configure notifications in its source is a 
handy feature.

Narrowing to email, it may be used by virtually everyone but much less 
people are able to setup mail filters accordingly to personal priorities 
of notifications. Ideally such tuning should be minimized, actually 
there is no common denominator for this kind of preferences, so some 
settings are unavoidable duty of users.

What is really sour is that notifications are often quite inconvenient 
for filtering.

I had positive experience with gerrit + redmine + sieve filters. Due to 
reach set of extended headers in mail messages it was possible to choose 
mail box based on committer, issue assignee or status change, result of 
build+tests. Failure of build of a my commit is rather important event. 
On the other hand I rarely visited mailbox with notification that build 
is started for someone else or even for me. A few iterations of filter 
tuning was stored in git.

For notifications from bitbucket and jira it was much harder or even 
impossible to determine the precise reason and configuring filters in 
outlook was a pain. There was no convenient set of X-... headers. I did 
not mange to approach to configuration that I considered as convenient 
from my previous experience.

Messengers are horror in the sense of customization and filtering of 
notifications. Channels are hard coded, instruments to suppress some 
messages are rather rude.

To avoid suffer due to email, development tools should be created with 
care and their users should be aware of features like filtering.

P.S. I have not checked whether notifications from SourceHut have reach 
enough metadata.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: SourceHut for Emacs (was: Gitlab Migration)
  2021-08-31 12:03             ` Eli Zaretskii
@ 2021-09-01 22:40               ` Yuan Fu
  2021-09-02  6:32                 ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Yuan Fu @ 2021-09-01 22:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, Emacs Devel



> On Aug 31, 2021, at 5:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 30 Aug 2021 13:17:42 -0700
>> Cc: emacs-devel@gnu.org
>> 
>>> So at this stage, I personally don't see much point looking for other
>>> tools.  Instead I'm just wondering how to get us to use SourceHut
>>> (i.e. how to resolve the problems that might stand in the way, such as
>>> getting an instance up and running on GNU machines, starting to use it
>>> "on the side" to see in practice what issues we'll need
>>> fixed/improved/added before we can really switch, etc...).
>>> 
>>> An obvious first issue is the one seen in Theodor's example:
>>> https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
>>> where the rendering of this email in the web interface completely hides
>>> the actual patch being sent.
>>> 
>> 
>> Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.
> 
> They are already participating in these discussions here.

Please forgive my ignorance, then ;-)

Yuan


^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 11:43                     ` Dmitry Gutov
  2021-08-31 16:03                       ` João Távora
  2021-08-31 16:21                       ` John Yates
@ 2021-09-02  3:37                       ` Richard Stallman
  2 siblings, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-09-02  3:37 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: eliz, danflscr, philipk, monnier, emacs-devel

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

  > The above is literally my observations 
  > on our decision-making in the area.

The substance of your statement may be based on observations.  It may
be a valid position -- I don't know.  But the way you said it is
sarcastic:

  > making sure that each
  > key binding that has been with us for a number of years, is left
  > unchanged for ever.

You have not had time to observe anything last "for ever".
None of us ever does.  That is an exaggeration, and it is sarcasm.

  >           We hate to risk inconveniencing existing users.

That is also a sarcastic way of making the point.

  > appealing to newcomers (and/or trying to adopt contemporary usability
  > practices) is of much lesser priority than,

Perhaps we do give it lower priority.  Perhaps it correct to do so.
It isn't bad to argue for the other position, but doing so with sarcasm
makes it more of a fight.

Sarcasm increases antagonism regardless of whether the point is valid.

If you don't try to avoid sarcasm, you will continue bringing acrimony.
Instead of convincing people, you're likely to entrench their positions.
Please agree to help keep discussion friendly.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: rmail threading
  2021-08-31 12:47                             ` Eli Zaretskii
@ 2021-09-02  3:37                               ` Richard Stallman
  2021-09-02  6:43                                 ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-09-02  3:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

  > Once you request a summary based on filtering, the unfiltered summary
  > is gone.  So I can no longer quickly and conveniently look for
  > messages that were filtered out by scrolling the summary buffer or by
  > searching in it.

I see your point (though M-s will search through all messages, regardless of
the summary).  I don't notice this because I never make an unfiltered summary.

This suggests we should have a convenient way to make multiple
summaries of a single Rmail buffer, and keep them in parallel.
What do you think of that?

  > > A summary in Rmail doesn't stop you from looking at messages not
  > > included in it.  I do that frequently.

  > Can you tell how do you do that?

If you have the Rmail buffer selected, the summary does not affect the
ordinary Rmail commands.  They move through the whole file unaffected
by the summary.

  > And I have one additional question about your request to have a
  > summary-by-thread: is it okay to request that the user first sorts the
  > messages by date (C-c C-s C-d), before summarizing the thread?

That would be a pain in the neck for me.  I don't want to reorder
RMAIL file.

If you go through all the messages making a Lispy data structure that
records the most important header fields of each, and its message
number, it would be pretty easy to sort that data structure and then
find the threads in it.  Then you could display the thread summary
either by send order or by order in the Rmail file.

Hmm, it would be interesting to make the Rmail sort commands operate
on a summary buffer by sorting the summary instead of the Rmail file.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-01 11:35                               ` John Yates
  2021-09-01 12:36                                 ` Eli Zaretskii
@ 2021-09-02  3:38                                 ` Richard Stallman
  2021-09-02 19:02                                   ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Richard Stallman @ 2021-09-02  3:38 UTC (permalink / raw)
  To: John Yates; +Cc: philipk, danflscr, emacs-devel, monnier, dgutov, eliz

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

  > Ah, but the model is opt-in to change, not opt-out.  Thus
  > opponents of change start off with an advantage 

That's ok.  We don't have any obligation to be "fair" to 
wishes for changes that other users don't like.

  > * Previews of features that will become defaults with opt-out

It is useful to offer previews of changed interfaces, but whether
to make the other interface the default some day is a question we
should decide after seeing users' reaction -- not in advance.


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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: SourceHut for Emacs (was: Gitlab Migration)
  2021-09-01 22:40               ` Yuan Fu
@ 2021-09-02  6:32                 ` Eli Zaretskii
  0 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02  6:32 UTC (permalink / raw)
  To: Yuan Fu; +Cc: monnier, emacs-devel

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 1 Sep 2021 15:40:07 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs Devel <emacs-devel@gnu.org>
> 
> >> Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.
> > 
> > They are already participating in these discussions here.
> 
> Please forgive my ignorance, then ;-)

No need to apologize, and nothing to forgive.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: rmail threading
  2021-09-02  3:37                               ` Richard Stallman
@ 2021-09-02  6:43                                 ` Eli Zaretskii
  2021-09-04  3:39                                   ` Richard Stallman
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02  6:43 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Sep 2021 23:37:51 -0400
> 
> This suggests we should have a convenient way to make multiple
> summaries of a single Rmail buffer, and keep them in parallel.
> What do you think of that?

That'd help, yes.  Still, the need to switch between different summary
buffers is less convenient, IMO.

>   > > A summary in Rmail doesn't stop you from looking at messages not
>   > > included in it.  I do that frequently.
> 
>   > Can you tell how do you do that?
> 
> If you have the Rmail buffer selected, the summary does not affect the
> ordinary Rmail commands.  They move through the whole file unaffected
> by the summary.

Yes, of course.  But that means you move by single message, which is
very inconvenient when you search for something.  M-s could help, but
M-s still leaves you looking at the inbox through a single-message
loophole.

>   > And I have one additional question about your request to have a
>   > summary-by-thread: is it okay to request that the user first sorts the
>   > messages by date (C-c C-s C-d), before summarizing the thread?
> 
> That would be a pain in the neck for me.  I don't want to reorder
> RMAIL file.

Too bad.

> If you go through all the messages making a Lispy data structure that
> records the most important header fields of each, and its message
> number, it would be pretty easy to sort that data structure and then
> find the threads in it.  Then you could display the thread summary
> either by send order or by order in the Rmail file.

Yes, that's more or less what Gnus does.  So I think the best way of
doing that would be to borrow the code from Gnus.  I hoped to avoid
that complexity, including the need to process all the threads before
one can walk a single thread.  I usually leave in INBOX old messages
that I need to consult frequently, so my INBOX file is very large, and
processing all of it for threads could take a while.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:38       ` dick
  2021-08-26 19:51         ` Eli Zaretskii
  2021-08-27  6:26         ` tomas
@ 2021-09-02 11:06         ` Alexander Adolf
  2021-09-02 11:13           ` Alexander Adolf
  2021-09-02 12:12           ` Eli Zaretskii
  2 siblings, 2 replies; 525+ messages in thread
From: Alexander Adolf @ 2021-09-02 11:06 UTC (permalink / raw)
  To: dick, Eli Zaretskii; +Cc: Dmitry Gutov, danflscr, emacs-devel


dick <dick.r.chiang@gmail.com> writes:

> * Newcomer suggests PR-based workflow citing youth.  Check.
>
> * Veterans chime in, citing the obvious reasons-for and the
> political reasons-against.  Check.
>
> * EZ cites his *sui generis* argument that a web-based workflow is actually
> *more* work than mailing patches around.  Check.
>
> * Someone announces his intention to begin the necessary work.  Check.
>
> * Someone remarks how discussion on emacs-devel repeats itself.  Now checked.

Nice. Thanks for the laugh!

But back to serious business. This is a long thread (297 on m y machine
at the time of this writing), and - in all honesty - that's not entirely
unexpected.

There is merit in both, keeping long-timers happy, and in lowering the
perceived entry barriers for potential new contributors. I would assume
that the smallest common denominator, which we all can agree to, would
be: "must not alienate/deter neither long-timers, nor newbies".

Thus, the magic words would seem to be "backwards compatibility", and
"migration path".

"backwards compatibility" := Everything that works via email now, must
equally work via email with the new system.

"migration path" := It must be possible to try out one function on the
new system, whilst still using all other functions via email.

If the new system has more functions, or makes some things easier, then
there could even be an incentive for the long-timers to look into the
new system.

Finally, a remark on issue/bug tracking. I have used a great many
trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
margin. The differentiating feature is blocks/depends-on. Many issue
trackers (including those in the various git hosting platforms) lack
this feature altogether. Those trackers who have it, often provide a
limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
another bug, can itself not be blocked by other bugs), or make it
awkward to use (e.g. you have to create a new bug as a subtask of
an existing one, and existing bugs cannot be made into subtasks any more
once created).

Hence my plea: debbugs ought to remain part of whatever any new system
might be.

Just my two cents anyway.


Many thanks and looking forward to your thoughts,

  --alex



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 11:06         ` Alexander Adolf
@ 2021-09-02 11:13           ` Alexander Adolf
  2021-09-02 12:12           ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Alexander Adolf @ 2021-09-02 11:13 UTC (permalink / raw)
  To: dick, Eli Zaretskii; +Cc: Dmitry Gutov, danflscr, emacs-devel


Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> [...]
> Finally, a remark on issue/bug tracking. I have used a great many
> trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
> margin. The differentiating feature is blocks/depends-on. Many issue
> trackers (including those in the various git hosting platforms) lack
> this feature altogether. Those trackers who have it, often provide a
> limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
> another bug, can itself not be blocked by other bugs), or make it
> awkward to use (e.g. you have to create a new bug as a subtask of
> an existing one, and existing bugs cannot be made into subtasks any more
> once created).
>
> Hence my plea: debbugs ought to remain part of whatever any new system
> might be.
> [...]

This discussion might be of interest in this context:

https://www.reddit.com/r/linux/comments/6qoqqi/gnome_wants_to_move_away_from_bugzilla_for_their/



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 11:06         ` Alexander Adolf
  2021-09-02 11:13           ` Alexander Adolf
@ 2021-09-02 12:12           ` Eli Zaretskii
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02 12:12 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: dgutov, danflscr, dick.r.chiang, emacs-devel

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: emacs-devel@gnu.org, danflscr@gmail.com, Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 02 Sep 2021 13:06:32 +0200
> 
> Thus, the magic words would seem to be "backwards compatibility", and
> "migration path".
> 
> "backwards compatibility" := Everything that works via email now, must
> equally work via email with the new system.

"Everything" is not a requirement, IMO.  It's nice to have, but we do
so much with email that requiring nothing to change is too much.
There should be a way to get notifications via email about the
important stuff, and there should be a way to participate in
discussing issues via email, including sending patches.

> "migration path" := It must be possible to try out one function on the
> new system, whilst still using all other functions via email.

Also not necessarily a requirement: it's okay if several functions
must be tried together.  Nice to have, certainly.

> Finally, a remark on issue/bug tracking. I have used a great many
> trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
> margin. The differentiating feature is blocks/depends-on. Many issue
> trackers (including those in the various git hosting platforms) lack
> this feature altogether. Those trackers who have it, often provide a
> limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
> another bug, can itself not be blocked by other bugs), or make it
> awkward to use (e.g. you have to create a new bug as a subtask of
> an existing one, and existing bugs cannot be made into subtasks any more
> once created).

Well, I agree that this is a good feature, but we don't use it too
much here.  So it is not high on my list of important features that
I'd consider as blocking the migration.

> Hence my plea: debbugs ought to remain part of whatever any new system
> might be.

Not if the new platform learns to support blocking, right?

Thanks.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 21:52         ` Stefan Monnier
@ 2021-09-02 15:25           ` Daniel Brooks
  0 siblings, 0 replies; 525+ messages in thread
From: Daniel Brooks @ 2021-09-02 15:25 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Lars Ingebrigtsen, Clément Pit-Claudel, Eli Zaretskii, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Indeed.  But I expect that whatever we end up with, we (that is, the
>> Emacs maintainers) won't have to click around, and won't have to
>> actually merge anything directly.  That is, I expect to have a command
>> in Emacs that says "get that pull request as a patch, apply it, and
>> don't commit it".  So that we can fix stuff up before committing -- as
>> before.
>
> Personally I tend to just use `git am` which *does* commit, and then
> I use `--amend` or `rebase` to perform adjustments.  Git supports that
> particularly well.

Yes, we can already do all of this without “click[ing] around” on a web
page. It’s quite easy to fetch the commits that the merge request is
referring to and then use Git locally to add more commits, amend the
existing commits, etc.

I recommend using Magit to do this without even leaving Emacs.

Incidentally, GitHub makes it even easier to do this because they add a
ref for every merge request.

db48x



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-26 19:44         ` Eli Zaretskii
  2021-08-26 20:05           ` Dmitry Gutov
@ 2021-09-02 15:30           ` Daniel Brooks
  2021-09-02 16:03             ` Eli Zaretskii
  1 sibling, 1 reply; 525+ messages in thread
From: Daniel Brooks @ 2021-09-02 15:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: cpitclaudel, emacs-devel, Dmitry Gutov

Eli Zaretskii <eliz@gnu.org> writes:

> Way better than Github and its ilk, where I actually need to point my
> browser to the issue to see the comments.

I use the Magit and Forge packages to create, view, and reply to merge
requests from Github and Gitlab inside of Emacs. No web browser needed.

The only downside is that it doesn’t have an inbox–style view of new
comments that I might want to respond to. I’ve occasionally considered
using Forge as a Gnus backend, but haven’t yet gotten around to it.

db48x



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 15:30           ` Daniel Brooks
@ 2021-09-02 16:03             ` Eli Zaretskii
  2021-09-02 16:19               ` Óscar Fuentes
  2021-09-02 18:26               ` Daniel Brooks
  0 siblings, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02 16:03 UTC (permalink / raw)
  To: Daniel Brooks; +Cc: cpitclaudel, emacs-devel, dgutov

> From: Daniel Brooks <db48x@db48x.net>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  cpitclaudel@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 02 Sep 2021 08:30:55 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Way better than Github and its ilk, where I actually need to point my
> > browser to the issue to see the comments.
> 
> I use the Magit and Forge packages to create, view, and reply to merge
> requests from Github and Gitlab inside of Emacs. No web browser needed.

How do you know there was a merge request?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 16:03             ` Eli Zaretskii
@ 2021-09-02 16:19               ` Óscar Fuentes
  2021-09-02 16:47                 ` Eli Zaretskii
  2021-09-02 18:26               ` Daniel Brooks
  1 sibling, 1 reply; 525+ messages in thread
From: Óscar Fuentes @ 2021-09-02 16:19 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> I use the Magit and Forge packages to create, view, and reply to merge
>> requests from Github and Gitlab inside of Emacs. No web browser needed.
>
> How do you know there was a merge request?

You receive an e-mail notification with a link to the request.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 16:19               ` Óscar Fuentes
@ 2021-09-02 16:47                 ` Eli Zaretskii
  2021-09-02 17:01                   ` Yuri Khan
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02 16:47 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 02 Sep 2021 18:19:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I use the Magit and Forge packages to create, view, and reply to merge
> >> requests from Github and Gitlab inside of Emacs. No web browser needed.
> >
> > How do you know there was a merge request?
> 
> You receive an e-mail notification with a link to the request.

Right, so email is still very much part of the workflow being
described, which is not the "pure" Github-based workflow.  That was
exactly my point.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 16:47                 ` Eli Zaretskii
@ 2021-09-02 17:01                   ` Yuri Khan
  2021-09-02 17:09                     ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Yuri Khan @ 2021-09-02 17:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Óscar Fuentes, Emacs developers

On Thu, 2 Sept 2021 at 23:49, Eli Zaretskii <eliz@gnu.org> wrote:

> > > How do you know there was a merge request?
> >
> > You receive an e-mail notification with a link to the request.
>
> Right, so email is still very much part of the workflow being
> described, which is not the "pure" Github-based workflow.  That was
> exactly my point.

“Pure” GitHub-based workflow does not mean “no email whatsoever”.
GitHub users do not poll the website all day to see if they have any
pull requests or incoming comments — they react to mail notifications,
too.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 17:01                   ` Yuri Khan
@ 2021-09-02 17:09                     ` Eli Zaretskii
  2021-09-02 17:24                       ` Yuri Khan
                                         ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02 17:09 UTC (permalink / raw)
  To: Yuri Khan; +Cc: ofv, emacs-devel

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 3 Sep 2021 00:01:03 +0700
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> > Right, so email is still very much part of the workflow being
> > described, which is not the "pure" Github-based workflow.  That was
> > exactly my point.
> 
> “Pure” GitHub-based workflow does not mean “no email whatsoever”.
> GitHub users do not poll the website all day to see if they have any
> pull requests or incoming comments — they react to mail notifications,
> too.

How could they react to email notifications, if, as we are being told,
they don't open their mailboxes?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 17:09                     ` Eli Zaretskii
@ 2021-09-02 17:24                       ` Yuri Khan
  2021-09-02 17:33                         ` Eli Zaretskii
  2021-09-02 17:36                       ` Óscar Fuentes
  2021-09-02 17:40                       ` Dmitry Gutov
  2 siblings, 1 reply; 525+ messages in thread
From: Yuri Khan @ 2021-09-02 17:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Óscar Fuentes, Emacs developers

On Fri, 3 Sept 2021 at 00:09, Eli Zaretskii <eliz@gnu.org> wrote:
> > “Pure” GitHub-based workflow does not mean “no email whatsoever”.
> > GitHub users do not poll the website all day to see if they have any
> > pull requests or incoming comments — they react to mail notifications,
> > too.
>
> How could they react to email notifications, if, as we are being told,
> they don't open their mailboxes?

Are we being told that?

People became unaccustomed to interacting with other people via email,
is all. Email has become (1) an authentication mechanism (“please
enter your email address”, “we’ve sent you a temporary login code or
link”), and (2) the vessel for incoming notifications leading you back
to a website (“you were mentioned in a thread on Slack and did not
react to it in five minutes, click here to read it”).



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 17:24                       ` Yuri Khan
@ 2021-09-02 17:33                         ` Eli Zaretskii
  0 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-02 17:33 UTC (permalink / raw)
  To: Yuri Khan; +Cc: ofv, emacs-devel

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 3 Sep 2021 00:24:31 +0700
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > How could they react to email notifications, if, as we are being told,
> > they don't open their mailboxes?
> 
> Are we being told that?

Yes, read all about it up-thread.

> People became unaccustomed to interacting with other people via email,
> is all. Email has become (1) an authentication mechanism (“please
> enter your email address”, “we’ve sent you a temporary login code or
> link”), and (2) the vessel for incoming notifications leading you back
> to a website (“you were mentioned in a thread on Slack and did not
> react to it in five minutes, click here to read it”).

So you are saying that, while picking up a verification code, they
also read the Github notifications they've got?  I'd be surprised.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 17:09                     ` Eli Zaretskii
  2021-09-02 17:24                       ` Yuri Khan
@ 2021-09-02 17:36                       ` Óscar Fuentes
  2021-09-02 17:40                       ` Dmitry Gutov
  2 siblings, 0 replies; 525+ messages in thread
From: Óscar Fuentes @ 2021-09-02 17:36 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> > Right, so email is still very much part of the workflow being
>> > described, which is not the "pure" Github-based workflow.  That was
>> > exactly my point.
>> 
>> “Pure” GitHub-based workflow does not mean “no email whatsoever”.
>> GitHub users do not poll the website all day to see if they have any
>> pull requests or incoming comments — they react to mail notifications,
>> too.
>
> How could they react to email notifications, if, as we are being told,
> they don't open their mailboxes?

Sorry, I was not following this thread and just answered your question
based on what (I assume) fits your personal preferences.

On Github, e-mail is one method among others for receiving
notifications. You also can receive push notifications on your browser
and on your phone.




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 17:09                     ` Eli Zaretskii
  2021-09-02 17:24                       ` Yuri Khan
  2021-09-02 17:36                       ` Óscar Fuentes
@ 2021-09-02 17:40                       ` Dmitry Gutov
  2 siblings, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-02 17:40 UTC (permalink / raw)
  To: Eli Zaretskii, Yuri Khan; +Cc: ofv, emacs-devel

On 02.09.2021 20:09, Eli Zaretskii wrote:
>> From: Yuri Khan<yuri.v.khan@gmail.com>
>> Date: Fri, 3 Sep 2021 00:01:03 +0700
>> Cc: Óscar Fuentes<ofv@wanadoo.es>,
>>   Emacs developers<emacs-devel@gnu.org>
>>
>>> Right, so email is still very much part of the workflow being
>>> described, which is not the "pure" Github-based workflow.  That was
>>> exactly my point.
>> “Pure” GitHub-based workflow does not mean “no email whatsoever”.
>> GitHub users do not poll the website all day to see if they have any
>> pull requests or incoming comments — they react to mail notifications,
>> too.
> How could they react to email notifications, if, as we are being told,
> they don't open their mailboxes?
> 

I have told just the opposite in this very thread: they can and do use 
email, and routinely do that to view notifications about PRs, comments, 
and so on.

Not to mention general business emails, etc.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 16:03             ` Eli Zaretskii
  2021-09-02 16:19               ` Óscar Fuentes
@ 2021-09-02 18:26               ` Daniel Brooks
  1 sibling, 0 replies; 525+ messages in thread
From: Daniel Brooks @ 2021-09-02 18:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: cpitclaudel, dgutov, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Brooks <db48x@db48x.net>
>> Cc: Dmitry Gutov <dgutov@yandex.ru>,  cpitclaudel@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Thu, 02 Sep 2021 08:30:55 -0700
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Way better than Github and its ilk, where I actually need to point my
>> > browser to the issue to see the comments.
>> 
>> I use the Magit and Forge packages to create, view, and reply to merge
>> requests from Github and Gitlab inside of Emacs. No web browser needed.
>
> How do you know there was a merge request?

For the small projects I work on, it is sufficient to open the list of
merge requests from Magit. This is no different than opening my email
inbox to see if there are new emails. Unlike a real email inbox,
however, nothing is keeping track of which “messages” I have read; I
have to do that myself. For a large project I would want some other way
to keep track of that information.

Since there is no Gnus integration yet, I assume that most people read
their email notifications to find out what has changed, then use Forge
or some other means to act on that information. Now that I think about
it, I think that forges should provid all the merge requests via IMAP,
rather than inventing yet another rest api.

db48x



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02  3:38                                 ` Richard Stallman
@ 2021-09-02 19:02                                   ` Dmitry Gutov
  2021-09-02 20:35                                     ` Representation of the Emacs userbase on emacs-devel Philip Kaludercic
                                                       ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-02 19:02 UTC (permalink / raw)
  To: rms, John Yates; +Cc: eliz, emacs-devel, danflscr, philipk, monnier

On 02.09.2021 06:38, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    > Ah, but the model is opt-in to change, not opt-out.  Thus
>    > opponents of change start off with an advantage
> 
> That's ok.  We don't have any obligation to be "fair" to
> wishes for changes that other users don't like.

We're literally under no "obligation" to anything. But is it a good outcome?

Under the current system a sufficiently loud single user can effectively 
veto any change. Or at least 3-4 such users.

But even 5 or 10 users are in no way representative of our entire user base.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Representation of the Emacs userbase on emacs-devel
  2021-09-02 19:02                                   ` Dmitry Gutov
@ 2021-09-02 20:35                                     ` Philip Kaludercic
  2021-09-02 22:39                                       ` Dmitry Gutov
  2021-09-02 22:58                                       ` Qiantan Hong
  2021-09-03  6:06                                     ` Gitlab Migration Eli Zaretskii
  2021-09-05  3:41                                     ` Richard Stallman
  2 siblings, 2 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-09-02 20:35 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: danflscr, rms, emacs-devel, monnier, eliz, John Yates

Dmitry Gutov <dgutov@yandex.ru> writes:

> Under the current system a sufficiently loud single user can
> effectively veto any change. Or at least 3-4 such users.
>
> But even 5 or 10 users are in no way representative of our entire user base.

But don't they represent other users? The fundamental issue underlying
all of this is that different people have different ideas of who is
using Emacs. We cannot say if emacs-devel is representative of the
entire user base or not. One can certainly sense differences when
comparing it to different communities (HN, /r/emacs, /emg/, popular
bloggers, various developer groups, ...), but these all tend to skew
towards Emacs enthusiasts, so they cannot be seen as reliable metric
either.

I agree that the ability for a handful of users to veto changes can be
annoying, but how harmful it is should be decided on a case-to-case
basis. Do you (or anyone else) have any examples of where one or just a
few people prevented a change from being made that you think would have
been good in your eyes?

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-02 20:35                                     ` Representation of the Emacs userbase on emacs-devel Philip Kaludercic
@ 2021-09-02 22:39                                       ` Dmitry Gutov
  2021-09-03  6:28                                         ` Eli Zaretskii
  2021-09-05  3:39                                         ` Richard Stallman
  2021-09-02 22:58                                       ` Qiantan Hong
  1 sibling, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-02 22:39 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: danflscr, rms, emacs-devel, monnier, eliz, John Yates

On 02.09.2021 23:35, Philip Kaludercic wrote:
> But don't they represent other users?

Of course they do. But what proportion of users? By the virtue of simply 
being on this mailing list, we are already skewed toward an older, more 
conservative crowd. And then we make it a veto power if *some* 5 people 
from said crowd disapprove.

> The fundamental issue underlying
> all of this is that different people have different ideas of who is
> using Emacs. We cannot say if emacs-devel is representative of the
> entire user base or not. One can certainly sense differences when
> comparing it to different communities (HN,/r/emacs, /emg/, popular
> bloggers, various developer groups, ...), but these all tend to skew
> towards Emacs enthusiasts, so they cannot be seen as reliable metric
> either.

I'm not saying it's easy, but we don't even try. We don't try to make 
whole-userbase polls (we talked about it a few times over last years, 
and never went through), we don't make decisions based on polls made by 
other people (only one exception that comes to mind is Lars' initiative 
regarding ring-bell-function), and we never make decisions based on what 
"others" do. Even when it is clear that when all other editors have made 
a certain technical decision in a different way than we did, decades 
ago, we stick with it. And I'm not even talking about major disruptive 
changes like a switch to CUA would be.

> I agree that the ability for a handful of users to veto changes can be
> annoying, but how harmful it is should be decided on a case-to-case
> basis. Do you (or anyone else) have any examples of where one or just a
> few people prevented a change from being made that you think would have
> been good in your eyes?

Every recent discussion about a UI change has been like that. A 
suggestion is made, arguments added, some people disagree saying it 
won't jive with their workflow (never mind that Emacs is, in fact, 
customizable), and that's it. For example, the thread about bindings for 
undo-only+undo-redo, which would make Emacs friendlier to any user with 
experience in about any other text editing program out there.

Or take indent-tabs-mode, an old pet peeve of mine: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about 
contemporary practice, whole-industry polls, threads with personal 
opinions anywhere, threads with people expressing confusion about the 
current default behavior... but a few people say a change will be 
inconvenient -- and it moves nowhere.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-02 20:35                                     ` Representation of the Emacs userbase on emacs-devel Philip Kaludercic
  2021-09-02 22:39                                       ` Dmitry Gutov
@ 2021-09-02 22:58                                       ` Qiantan Hong
  1 sibling, 0 replies; 525+ messages in thread
From: Qiantan Hong @ 2021-09-02 22:58 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: danflscr, rms, Emacs Devel, Stefan Monnier, Dmitry Gutov,
	Eli Zaretskii, John Yates

> Under the current system a sufficiently loud single user can
> effectively veto any change. Or at least 3-4 such users.
> 
> But even 5 or 10 users are in no way representative of our entire user base.

Let reason speak, not individual.


^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 16:21                       ` John Yates
  2021-08-31 16:37                         ` Eli Zaretskii
@ 2021-09-03  3:09                         ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-09-03  3:09 UTC (permalink / raw)
  To: John Yates; +Cc: philipk, danflscr, emacs-devel, monnier, dgutov, eliz

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

  > Any changes that can attract new blood have my vote.

You can argue for that, and your arguments can in general have
influence.  But it isn't a matter of voting.  That's not how
we make the decisions about Emacs.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-31 19:33                         ` Dmitry Gutov
  2021-08-31 22:25                           ` João Távora
@ 2021-09-03  3:10                           ` Richard Stallman
  1 sibling, 0 replies; 525+ messages in thread
From: Richard Stallman @ 2021-09-03  3:10 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, emacs-devel, joaotavora, eliz, monnier

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

  > Sure, let's keep the barriers to contribution, both formal and informal 
  > ones. That will serve us well.

One way to encourage people to stick around is to be kind in the
discussion list.  For instance, not to use sarcasm.  Whatever point
you wish to make, you can make it in a kind way.

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





^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-08-30 12:55                     ` Dmitry Gutov
@ 2021-09-03  4:57                       ` Elias Mårtenson
  2021-09-03  5:26                         ` Ihor Radchenko
                                           ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: Elias Mårtenson @ 2021-09-03  4:57 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: philipk, Daniel Fleischer, Richard Stallman, emacs-devel,
	Stefan Monnier, Eli Zaretskii

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

Den mån 30 aug. 2021 20:57Dmitry Gutov <dgutov@yandex.ru> skrev:

>
> And whether existing muscle memory can be sacrificed for better
> usability. And/or for reduced suffering in newcomers.
>

If whatever is popular equals better, then Emacs would have been rewritten
in Java already, no wait, Ruby, no actually Python, sorry I meant
Javascript.

A lot of things are familiar to a lot of people, but familiarity is
orthogonal to quality.

>

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  4:57                       ` Elias Mårtenson
@ 2021-09-03  5:26                         ` Ihor Radchenko
  2021-09-03  6:40                           ` Eli Zaretskii
  2021-09-03  7:26                           ` Philip Kaludercic
  2021-09-03 10:20                         ` Gitlab Migration Dmitry Gutov
  2021-09-03 10:45                         ` Gitlab Migration Stefan Kangas
  2 siblings, 2 replies; 525+ messages in thread
From: Ihor Radchenko @ 2021-09-03  5:26 UTC (permalink / raw)
  To: Elias Mårtenson
  Cc: philipk, Daniel Fleischer, Richard Stallman, emacs-devel,
	Stefan Monnier, Dmitry Gutov, Eli Zaretskii

Elias Mårtenson <lokedhs@gmail.com> writes:

> If whatever is popular equals better, then Emacs would have been rewritten
> in Java already, no wait, Ruby, no actually Python, sorry I meant
> Javascript.

> A lot of things are familiar to a lot of people, but familiarity is
> orthogonal to quality.

Reducto ad absurdum? Of course, rewriting Emacs using different language
is not a good idea if the justification is merely the language
popularity. However, much smaller changes can be reverted if they do not
prove themselves useful.

Can Emacs have "experimental" and "stable" dev branches with the former
being more open to "popular" changes? Then, people who wish a more
"popular" approach can use the experimental branch without disturbing
more conservative users. If features in experimental branch prove their
usefulness and quality, they can be moved to the stable branch.

Best,
Ihor




^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-02 19:02                                   ` Dmitry Gutov
  2021-09-02 20:35                                     ` Representation of the Emacs userbase on emacs-devel Philip Kaludercic
@ 2021-09-03  6:06                                     ` Eli Zaretskii
  2021-09-03  6:12                                       ` Lars Ingebrigtsen
  2021-09-05  3:41                                     ` Richard Stallman
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03  6:06 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

> Cc: eliz@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 2 Sep 2021 22:02:25 +0300
> 
> >    > Ah, but the model is opt-in to change, not opt-out.  Thus
> >    > opponents of change start off with an advantage
> > 
> > That's ok.  We don't have any obligation to be "fair" to
> > wishes for changes that other users don't like.
> 
> We're literally under no "obligation" to anything. But is it a good outcome?
> 
> Under the current system a sufficiently loud single user can effectively 
> veto any change. Or at least 3-4 such users.
> 
> But even 5 or 10 users are in no way representative of our entire user base.

Opt-in changes are an effective way of dealing with such resistance.
They cannot be easily vetoed.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  6:06                                     ` Gitlab Migration Eli Zaretskii
@ 2021-09-03  6:12                                       ` Lars Ingebrigtsen
  2021-09-03  6:44                                         ` Eli Zaretskii
                                                           ` (3 more replies)
  0 siblings, 4 replies; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-03  6:12 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, rms, emacs-devel, monnier, Dmitry Gutov, john

Eli Zaretskii <eliz@gnu.org> writes:

> Opt-in changes are an effective way of dealing with such resistance.
> They cannot be easily vetoed.

We have previously discussed extending the concept of a "theme", which
is currently basically just visual.  I think the way forward here is to
allow people to create opinionated views on how Emacs should work (from
keystrokes on up to basically...  anything), and include these in Emacs.

New users, when starting Emacs, would then be able to choose between,
say, five of these mega-themes on the start-up screen by just clicking
them.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-02 22:39                                       ` Dmitry Gutov
@ 2021-09-03  6:28                                         ` Eli Zaretskii
  2021-09-03 10:34                                           ` Dmitry Gutov
  2021-09-04  5:34                                           ` Yuan Fu
  2021-09-05  3:39                                         ` Richard Stallman
  1 sibling, 2 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03  6:28 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

> Cc: rms@gnu.org, John Yates <john@yates-sheets.org>, eliz@gnu.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 01:39:05 +0300
> 
> > I agree that the ability for a handful of users to veto changes can be
> > annoying, but how harmful it is should be decided on a case-to-case
> > basis. Do you (or anyone else) have any examples of where one or just a
> > few people prevented a change from being made that you think would have
> > been good in your eyes?
> 
> Every recent discussion about a UI change has been like that. A 
> suggestion is made, arguments added, some people disagree saying it 
> won't jive with their workflow (never mind that Emacs is, in fact, 
> customizable), and that's it. For example, the thread about bindings for 
> undo-only+undo-redo, which would make Emacs friendlier to any user with 
> experience in about any other text editing program out there.

That's only true for changes of the default behavior, and key bindings
are examples of such a change, at least the way they are proposed.
There was talk about introducing a minor mode which would then be free
to make controversial changes, including key bindings, but no one
stepped forward to write such a mode.  Which I think is a pity, given
how easy it should be to do that, and how many problems and
frustrations it could potentially solve.

Once again: significant changes in behavior should generally be
introduced as opt-in features, then the friction will be much lower
and in the long run we could perhaps introduce changes at a faster
pace.  Thus, people who insist on making changes in the default
behavior are shooting themselves (and Emacs, if their opinions are
right) in the foot, IME.

> Or take indent-tabs-mode, an old pet peeve of mine: 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about 
> contemporary practice, whole-industry polls, threads with personal 
> opinions anywhere, threads with people expressing confusion about the 
> current default behavior... but a few people say a change will be 
> inconvenient -- and it moves nowhere.

indent-tabs-mode is an existing option, so your insistence on turning
it on by default in the face of resistance is ... peculiar.  We did
turn it on in some of our sources.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  5:26                         ` Ihor Radchenko
@ 2021-09-03  6:40                           ` Eli Zaretskii
  2021-09-03  7:26                           ` Philip Kaludercic
  1 sibling, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03  6:40 UTC (permalink / raw)
  To: Ihor Radchenko
  Cc: philipk, danflscr, rms, lokedhs, emacs-devel, monnier, dgutov

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,  Daniel Fleischer
>  <danflscr@gmail.com>,  Richard Stallman <rms@gnu.org>,  emacs-devel
>  <emacs-devel@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>,  Eli
>  Zaretskii <eliz@gnu.org>
> Date: Fri, 03 Sep 2021 13:26:13 +0800
> 
> Can Emacs have "experimental" and "stable" dev branches with the former
> being more open to "popular" changes?

It certainly can, if Someone™ steps forward to take care of them:
review patches, decide which features fit and which don't, perhaps
produce snapshots, etc.  We'd also need to discuss procedures how
stuff is merged from those branches to master.  Volunteers are welcome
to work on this.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  6:12                                       ` Lars Ingebrigtsen
@ 2021-09-03  6:44                                         ` Eli Zaretskii
  2021-09-03 10:16                                           ` Stefan Kangas
  2021-09-03  7:28                                         ` Philip Kaludercic
                                                           ` (2 subsequent siblings)
  3 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03  6:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: philipk, danflscr, rms, emacs-devel, monnier, dgutov, john

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,
>   danflscr@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  john@yates-sheets.org
> Date: Fri, 03 Sep 2021 08:12:04 +0200
> 
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.
> 
> New users, when starting Emacs, would then be able to choose between,
> say, five of these mega-themes on the start-up screen by just clicking
> them.

Sure, SGTM.  I hope such themes will be developed and added to Emacs.
That's one way of having several opt-in changes in behavior that can
be turned on and off with a single command.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  5:26                         ` Ihor Radchenko
  2021-09-03  6:40                           ` Eli Zaretskii
@ 2021-09-03  7:26                           ` Philip Kaludercic
  2021-09-03 10:26                             ` Dmitry Gutov
  1 sibling, 1 reply; 525+ messages in thread
From: Philip Kaludercic @ 2021-09-03  7:26 UTC (permalink / raw)
  To: Ihor Radchenko
  Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
	emacs-devel, Stefan Monnier, Dmitry Gutov, Eli Zaretskii

Ihor Radchenko <yantar92@gmail.com> writes:

> Can Emacs have "experimental" and "stable" dev branches with the former
> being more open to "popular" changes? Then, people who wish a more
> "popular" approach can use the experimental branch without disturbing
> more conservative users. If features in experimental branch prove their
> usefulness and quality, they can be moved to the stable branch.

In some sense this exists with prepared configurations (or
"distributions" as some call them). The changes they can make are not
exactly the same as a "experimental" branch could, but they can do a lot
of superficial and organisational changes.

The issue there is that prepared configurations bundle a lot of options
together, so it is harder to evaluate what is popular and what the
maintainers of these projects prefer.

An idea I was playing around with for a while was to build a website to
generate Emacs configurations. You'd select what you like to use, what
you don't want, etc. and it would let you download an init.el
file. Optionally, the user could select to have their preferences
anonymously logged, for statistical purposes (comparable to Debian's
popcon). Of course the data could be manipulated easily, so it is
debatable how reliable it would be.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  6:12                                       ` Lars Ingebrigtsen
  2021-09-03  6:44                                         ` Eli Zaretskii
@ 2021-09-03  7:28                                         ` Philip Kaludercic
  2021-09-03  7:31                                           ` Eli Zaretskii
  2021-09-03 10:59                                         ` Dmitry Gutov
  2021-09-04 16:24                                         ` Gitlab Migration Christian Vanderwall
  3 siblings, 1 reply; 525+ messages in thread
From: Philip Kaludercic @ 2021-09-03  7:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: danflscr, rms, emacs-devel, monnier, Dmitry Gutov, Eli Zaretskii, john

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Opt-in changes are an effective way of dealing with such resistance.
>> They cannot be easily vetoed.
>
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.

Conversely, themes could also be used to reset changes. You could have
an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
to reset the defaults to whatever they are used to.

> New users, when starting Emacs, would then be able to choose between,
> say, five of these mega-themes on the start-up screen by just clicking
> them.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  7:28                                         ` Philip Kaludercic
@ 2021-09-03  7:31                                           ` Eli Zaretskii
  2021-09-03  8:35                                             ` Philip Kaludercic
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03  7:31 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: danflscr, rms, emacs-devel, monnier, dgutov, larsi, john

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Dmitry Gutov <dgutov@yandex.ru>,
>   danflscr@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  john@yates-sheets.org
> Date: Fri, 03 Sep 2021 07:28:29 +0000
> 
> Conversely, themes could also be used to reset changes. You could have
> an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
> to reset the defaults to whatever they are used to.

Yes.  This was all discussed in the past, I just hope it will happen
some time soon.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  7:31                                           ` Eli Zaretskii
@ 2021-09-03  8:35                                             ` Philip Kaludercic
  0 siblings, 0 replies; 525+ messages in thread
From: Philip Kaludercic @ 2021-09-03  8:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: danflscr, rms, emacs-devel, monnier, dgutov, larsi, john

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Dmitry Gutov <dgutov@yandex.ru>,
>>   danflscr@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org,
>>   monnier@iro.umontreal.ca,  john@yates-sheets.org
>> Date: Fri, 03 Sep 2021 07:28:29 +0000
>> 
>> Conversely, themes could also be used to reset changes. You could have
>> an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
>> to reset the defaults to whatever they are used to.
>
> Yes.  This was all discussed in the past, I just hope it will happen
> some time soon.

Ah, that is good to hear. The last time I was following one of the
discussions that proposed something like this, it seemed as though the
list was against it. I'll look into how successfully this could be done.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  6:44                                         ` Eli Zaretskii
@ 2021-09-03 10:16                                           ` Stefan Kangas
  0 siblings, 0 replies; 525+ messages in thread
From: Stefan Kangas @ 2021-09-03 10:16 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Philip K.,
	danflscr, Richard Stallman, Emacs developers, Stefan Monnier,
	Dmitry Gutov, Lars Ingebrigtsen, John Yates

Eli Zaretskii <eliz@gnu.org> writes:

> > We have previously discussed extending the concept of a "theme", which
> > is currently basically just visual.  I think the way forward here is to
> > allow people to create opinionated views on how Emacs should work (from
> > keystrokes on up to basically...  anything), and include these in Emacs.
> >
> > New users, when starting Emacs, would then be able to choose between,
> > say, five of these mega-themes on the start-up screen by just clicking
> > them.
>
> Sure, SGTM.  I hope such themes will be developed and added to Emacs.
> That's one way of having several opt-in changes in behavior that can
> be turned on and off with a single command.

I agree.  I have proposed to name such themes "profiles" in the past, see e.g.:

    https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02032.html



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  4:57                       ` Elias Mårtenson
  2021-09-03  5:26                         ` Ihor Radchenko
@ 2021-09-03 10:20                         ` Dmitry Gutov
  2021-09-06  3:05                           ` like a module system Richard Stallman
  2021-09-03 10:45                         ` Gitlab Migration Stefan Kangas
  2 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 10:20 UTC (permalink / raw)
  To: Elias Mårtenson
  Cc: philipk, Daniel Fleischer, Richard Stallman, emacs-devel,
	Stefan Monnier, Eli Zaretskii

On 03.09.2021 07:57, Elias Mårtenson wrote:
> If whatever is popular equals better, then Emacs would have been 
> rewritten in Java already, no wait, Ruby, no actually Python, sorry I 
> meant Javascript.

And there is a lot of good stuff we would take from any of the examples 
above, if we could: a module system, concurrency options, a faster 
regexp engine.

Looking at the popular options doesn't mean adopting their changes 
wholesale. But we don't even do the little stuff that we can.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  7:26                           ` Philip Kaludercic
@ 2021-09-03 10:26                             ` Dmitry Gutov
  2021-09-03 11:11                               ` Philip Kaludercic
  2021-09-06  3:05                               ` Emacs default bindings Richard Stallman
  0 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 10:26 UTC (permalink / raw)
  To: Philip Kaludercic, Ihor Radchenko
  Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
	emacs-devel, Stefan Monnier, Eli Zaretskii

On 03.09.2021 10:26, Philip Kaludercic wrote:
> Ihor Radchenko<yantar92@gmail.com>  writes:
> 
>> Can Emacs have "experimental" and "stable" dev branches with the former
>> being more open to "popular" changes? Then, people who wish a more
>> "popular" approach can use the experimental branch without disturbing
>> more conservative users. If features in experimental branch prove their
>> usefulness and quality, they can be moved to the stable branch.
> In some sense this exists with prepared configurations (or
> "distributions" as some call them). The changes they can make are not
> exactly the same as a "experimental" branch could, but they can do a lot
> of superficial and organisational changes.

And as those distributions have been around for some time, we could look 
at the changes in options they made and strongly consider making the 
changes in defaults where those distributions agree, or largely agree.

Those kind of arguments, however, aren't generally accepted around here 
either.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-03  6:28                                         ` Eli Zaretskii
@ 2021-09-03 10:34                                           ` Dmitry Gutov
  2021-09-03 11:19                                             ` Eli Zaretskii
  2021-09-04  5:34                                           ` Yuan Fu
  1 sibling, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 10:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

On 03.09.2021 09:28, Eli Zaretskii wrote:
> That's only true for changes of the default behavior, and key bindings
> are examples of such a change, at least the way they are proposed.
> There was talk about introducing a minor mode which would then be free
> to make controversial changes, including key bindings, but no one
> stepped forward to write such a mode.  Which I think is a pity, given
> how easy it should be to do that, and how many problems and
> frustrations it could potentially solve.

Again you try to change any discussion of a change into an "addition". 
Something that wouldn't change anything in the default behavior.

> Once again: significant changes in behavior should generally be
> introduced as opt-in features, then the friction will be much lower
> and in the long run we could perhaps introduce changes at a faster
> pace.  Thus, people who insist on making changes in the default
> behavior are shooting themselves (and Emacs, if their opinions are
> right) in the foot, IME.

A lot of the time I'm talking about features that are already available. 
There's nothing to "introduce". But simply by having a wrong default we 
make Emacs harder to adopt with little benefit.

>> Or take indent-tabs-mode, an old pet peeve of mine:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about
>> contemporary practice, whole-industry polls, threads with personal
>> opinions anywhere, threads with people expressing confusion about the
>> current default behavior... but a few people say a change will be
>> inconvenient -- and it moves nowhere.
> 
> indent-tabs-mode is an existing option, so your insistence on turning
> it on by default in the face of resistance is ... peculiar.  We did
> turn it on in some of our sources.

Turning it off by default.

What's so peculiar about changing the behavior that flies in the face of 
existing practice in all programming languages out there? And which 
causes confusion in new users?

The way it is implemented made sense decades ago, but these days even 
users who want tabs for indentation are surprised by Emacs behavior in 
this area (because most of those users want 1 tab to mean 1 indentation 
level).



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  4:57                       ` Elias Mårtenson
  2021-09-03  5:26                         ` Ihor Radchenko
  2021-09-03 10:20                         ` Gitlab Migration Dmitry Gutov
@ 2021-09-03 10:45                         ` Stefan Kangas
  2021-09-05  3:44                           ` Richard Stallman
  2021-09-05  3:44                           ` Richard Stallman
  2 siblings, 2 replies; 525+ messages in thread
From: Stefan Kangas @ 2021-09-03 10:45 UTC (permalink / raw)
  To: Elias Mårtenson
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Dmitry Gutov, Eli Zaretskii

Elias Mårtenson <lokedhs@gmail.com> writes:

> If whatever is popular equals better, then Emacs would have been rewritten in Java already, no wait, Ruby, no actually Python, sorry I meant Javascript.
>
> A lot of things are familiar to a lot of people, but familiarity is orthogonal to quality.

Many of the things some of us would like to see changed are not mainly
characterized by being particularly good. They are just different.

To give a concrete example, the kill ring is objectively better/more
powerful than the undo/redo you find in other text editors. It is also
harder to use, of course, but that's the territory Emacs thrives in.

But why is kill-region bound to C-w instead of C-x? I'm not really
advocating to change that key binding, but it is also clearly not
better. In fact, it is worse, precisely because one might as well use
the more familiar key binding. If we started Emacs from a clean slate
today, we would obviously have put kill-region on C-x.

We would in my opinion do well to take opportunities to make Emacs
behave more in line with modern user expectations. As the above
example shows, that is not always going to be easy. But there is no
reason to expect that careful work here would not lead to a better, if
slightly different, Emacs. (And if you hate the results, Emacs is
always going to be customizable. So you can have your cake, and eat it
too.)



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03  6:12                                       ` Lars Ingebrigtsen
  2021-09-03  6:44                                         ` Eli Zaretskii
  2021-09-03  7:28                                         ` Philip Kaludercic
@ 2021-09-03 10:59                                         ` Dmitry Gutov
  2021-09-03 11:06                                           ` Lars Ingebrigtsen
                                                             ` (3 more replies)
  2021-09-04 16:24                                         ` Gitlab Migration Christian Vanderwall
  3 siblings, 4 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 10:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii
  Cc: philipk, danflscr, rms, emacs-devel, monnier, john

On 03.09.2021 09:12, Lars Ingebrigtsen wrote:
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.

A key bindings theme is a nice enough concept (for example, to create a 
native set of key bindings that follows the CUA convention). For that, 
indeed what's left is for someone to do the work.

Which is significant -- moving all current default bindings around to 
free up C-x, C-c, C-v, C-a and C-z is a big task, especially if one 
wants to interoperate with bindings made by third-party modes as well.

But I don't really want to migrate to CUA, personally. Do we not want 
our other users to enjoy undo-redo? Having a separate theme for every 
little proposed change seems silly.

And having a theme to just make indent-tabs-mode behavior sane, that 
would just be ridiculous.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 10:59                                         ` Dmitry Gutov
@ 2021-09-03 11:06                                           ` Lars Ingebrigtsen
  2021-09-03 11:16                                             ` Dmitry Gutov
  2021-09-03 11:26                                           ` Eli Zaretskii
                                                             ` (2 subsequent siblings)
  3 siblings, 1 reply; 525+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-03 11:06 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: philipk, danflscr, rms, emacs-devel, monnier, Eli Zaretskii, john

Dmitry Gutov <dgutov@yandex.ru> writes:

> But I don't really want to migrate to CUA, personally. Do we not want
> our other users to enjoy undo-redo? Having a separate theme for every
> little proposed change seems silly.

Yes, that's not what I think we should add (and as Stefan reminded us,
the previous time over we called the concept "profiles").  These would
be big things that change Emacs in sweeping, opinionated ways a la
Spacemacs, and there would only be half a dozen of them.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 10:26                             ` Dmitry Gutov
@ 2021-09-03 11:11                               ` Philip Kaludercic
  2021-09-03 11:31                                 ` Dmitry Gutov
  2021-09-06  3:05                               ` Emacs default bindings Richard Stallman
  1 sibling, 1 reply; 525+ messages in thread
From: Philip Kaludercic @ 2021-09-03 11:11 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
	Ihor Radchenko, emacs-devel, Stefan Monnier, Eli Zaretskii

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03.09.2021 10:26, Philip Kaludercic wrote:
>> Ihor Radchenko<yantar92@gmail.com>  writes:
>> 
>>> Can Emacs have "experimental" and "stable" dev branches with the former
>>> being more open to "popular" changes? Then, people who wish a more
>>> "popular" approach can use the experimental branch without disturbing
>>> more conservative users. If features in experimental branch prove their
>>> usefulness and quality, they can be moved to the stable branch.
>> In some sense this exists with prepared configurations (or
>> "distributions" as some call them). The changes they can make are not
>> exactly the same as a "experimental" branch could, but they can do a lot
>> of superficial and organisational changes.
>
> And as those distributions have been around for some time, we could
> look at the changes in options they made and strongly consider making
> the changes in defaults where those distributions agree, or largely
> agree.
>
> Those kind of arguments, however, aren't generally accepted around
> here either.

I guess because it is easy to conflate the changes they make. These
distributions and prepared configurations don't have to care about
backwards compatibility, to they are a lot more flexible to change
whatever they want. But there are different things:

* Rebinding existing commands to ...
  - different functionalities (C-x to kill)
  - stronger equivalents (M-/ to hippie-expand)
  - slightly different but more intuitive commands (M-z to zap-up-to-char)
* Binding commands to new keys (C-x p for project.el)
* Providing more or different packages by-default (various major modes
  not available in ELPA, use-package, ...)
* Enabling options by default ...
  - that might have been considered to intensive in the past
    (show-paren-mode, decreasing lazy-highlight-initial-delay, ...)
  - that change the default behaviour by trying to be intuitive (electric
    modes)
* Changing the default UI to ...
  - match modern design trends (adding blank space, adding those
    little triangles to the mode line, ...)
  - improve readability (changing the default theme, using more
    variable-width faces in the UI)

And I am sure there are more, but the point is that there are different
discussions and motivations behind these changes. Emacs is currently in
the weird position where it is already different but doesn't want to
confuse new users even more by disabling some commands by default
(upcase-region, narrow-to-region) or offer more power by default
(searching using regular expressions by default).

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 11:06                                           ` Lars Ingebrigtsen
@ 2021-09-03 11:16                                             ` Dmitry Gutov
  2021-09-03 12:11                                               ` João Távora
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 11:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: philipk, danflscr, rms, emacs-devel, monnier, Eli Zaretskii, john

On 03.09.2021 14:06, Lars Ingebrigtsen wrote:
> Yes, that's not what I think we should add (and as Stefan reminded us,
> the previous time over we called the concept "profiles").  These would
> be big things that change Emacs in sweeping, opinionated ways a la
> Spacemacs, and there would only be half a dozen of them.

We should not forget that, by maintaining those profiles, we would 
probably obligate any addition or change to the default key binding set 
to be adapted to all (or some) of these half a dozen profiles.

So the more we have of them, the more work we add to our contributors. 
Or potential bugs when we forget to do that.

That would basically extend to any method of bundling and maintaining 
sets of alternative configurations in the core.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-03 10:34                                           ` Dmitry Gutov
@ 2021-09-03 11:19                                             ` Eli Zaretskii
  2021-09-03 12:11                                               ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 11:19 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

> Cc: philipk@posteo.net, rms@gnu.org, john@yates-sheets.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 13:34:38 +0300
> 
> On 03.09.2021 09:28, Eli Zaretskii wrote:
> > That's only true for changes of the default behavior, and key bindings
> > are examples of such a change, at least the way they are proposed.
> > There was talk about introducing a minor mode which would then be free
> > to make controversial changes, including key bindings, but no one
> > stepped forward to write such a mode.  Which I think is a pity, given
> > how easy it should be to do that, and how many problems and
> > frustrations it could potentially solve.
> 
> Again you try to change any discussion of a change into an "addition". 
> Something that wouldn't change anything in the default behavior.

Because I think that's a much better way forward, in the long run.
But if you want to insist on changing the defaults without the opt-in
changes first, I guess we will be having this discussion many times in
the future.

> > indent-tabs-mode is an existing option, so your insistence on turning
> > it on by default in the face of resistance is ... peculiar.  We did
> > turn it on in some of our sources.
> 
> Turning it off by default.
> 
> What's so peculiar about changing the behavior that flies in the face of 
> existing practice in all programming languages out there? And which 
> causes confusion in new users?
> 
> The way it is implemented made sense decades ago, but these days even 
> users who want tabs for indentation are surprised by Emacs behavior in 
> this area (because most of those users want 1 tab to mean 1 indentation 
> level).

You tried convincing in this before, and you failed.  IME, at least on
my daytime job, source code produced by people these days with popular
IDEs (not Emacs) includes TABs.  So at least my experience disagrees
with yours.  Which might explain why this change didn't happen.

Someone suggested to have "themes" in Emacs which could change the
defaults of many settings in one simple command.  Why not invest the
energy we waste in these endless discussions in making that happen?
It at least would make the changes easier for newbies, if nothing
else.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 10:59                                         ` Dmitry Gutov
  2021-09-03 11:06                                           ` Lars Ingebrigtsen
@ 2021-09-03 11:26                                           ` Eli Zaretskii
  2021-09-03 12:08                                             ` Dmitry Gutov
  2021-09-06  3:06                                           ` Emacs default bindings Richard Stallman
  2021-09-06  3:06                                           ` indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel] Richard Stallman
  3 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 11:26 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, larsi, john

> Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca, john@yates-sheets.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 13:59:37 +0300
> 
> A key bindings theme is a nice enough concept (for example, to create a 
> native set of key bindings that follows the CUA convention). For that, 
> indeed what's left is for someone to do the work.
> 
> Which is significant -- moving all current default bindings around to 
> free up C-x, C-c, C-v, C-a and C-z is a big task, especially if one 
> wants to interoperate with bindings made by third-party modes as well.
> 
> But I don't really want to migrate to CUA, personally. Do we not want 
> our other users to enjoy undo-redo? Having a separate theme for every 
> little proposed change seems silly.
> 
> And having a theme to just make indent-tabs-mode behavior sane, that 
> would just be ridiculous.

Figuring out these (and other) issues is indeed not trivial.  I still
hope someone will pick up the gauntlet, though.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 11:11                               ` Philip Kaludercic
@ 2021-09-03 11:31                                 ` Dmitry Gutov
  2021-09-03 11:41                                   ` Eli Zaretskii
  2021-09-05  7:47                                   ` Gitlab Migration Lars Ingebrigtsen
  0 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 11:31 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: Daniel Fleischer, Richard Stallman, Elias Mårtenson,
	Ihor Radchenko, emacs-devel, Stefan Monnier, Eli Zaretskii

On 03.09.2021 14:11, Philip Kaludercic wrote:
> * Enabling options by default ...
>    - that might have been considered to intensive in the past
>      (show-paren-mode, decreasing lazy-highlight-initial-delay, ...)
>    - that change the default behaviour by trying to be intuitive (electric
>      modes)

One change I previously suggested is the value of 
uniquify-buffer-name-style to 'forward, which most distributions out 
there use.

It's a small difference, but again -- no go.

Another similar changes:

require-final-newline -> t

indent-tabs-mode -> nil (of course)

show-paren-mode seems universally acclaimed as well (though prelude and 
doom-emacs use smartparens for a similar effect), so why not enable it too.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 11:31                                 ` Dmitry Gutov
@ 2021-09-03 11:41                                   ` Eli Zaretskii
  2021-09-03 12:12                                     ` Dmitry Gutov
                                                       ` (3 more replies)
  2021-09-05  7:47                                   ` Gitlab Migration Lars Ingebrigtsen
  1 sibling, 4 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 11:41 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: philipk, danflscr, rms, lokedhs, yantar92, emacs-devel, monnier

> Cc: Ihor Radchenko <yantar92@gmail.com>, Elias Mårtenson
>  <lokedhs@gmail.com>, Daniel Fleischer <danflscr@gmail.com>,
>  Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 14:31:47 +0300
> 
> One change I previously suggested is the value of 
> uniquify-buffer-name-style to 'forward, which most distributions out 
> there use.
> 
> It's a small difference, but again -- no go.
> 
> Another similar changes:
> 
> require-final-newline -> t
> 
> indent-tabs-mode -> nil (of course)
> 
> show-paren-mode seems universally acclaimed as well (though prelude and 
> doom-emacs use smartparens for a similar effect), so why not enable it too.

There, you have already a list of options to include in a suitably
named "profile".  Why not add that to Emacs right now?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 11:26                                           ` Eli Zaretskii
@ 2021-09-03 12:08                                             ` Dmitry Gutov
  2021-09-03 12:17                                               ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 12:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, danflscr, rms, emacs-devel, monnier, larsi, john

On 03.09.2021 14:26, Eli Zaretskii wrote:
> Figuring out these (and other) issues is indeed not trivial.  I still
> hope someone will pick up the gauntlet, though.

Some of them can be figured by "someone" (e.g. the full resulting CUA 
layout), but please don't dodge the fundamental questions.

You reject the obvious and easy solution, after all.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 11:16                                             ` Dmitry Gutov
@ 2021-09-03 12:11                                               ` João Távora
  2021-09-03 12:14                                                 ` Dmitry Gutov
                                                                   ` (2 more replies)
  0 siblings, 3 replies; 525+ messages in thread
From: João Távora @ 2021-09-03 12:11 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Lars Ingebrigtsen, Eli Zaretskii, John Yates

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

On Fri, Sep 3, 2021, 12:45 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 03.09.2021 14:06, Lars Ingebrigtsen wrote:
> > Yes, that's not what I think we should add (and as Stefan reminded us,
> > the previous time over we called the concept "profiles").  These would
> > be big things that change Emacs in sweeping, opinionated ways a la
> > Spacemacs, and there would only be half a dozen of them.
>
> We should not forget that, by maintaining those profiles, we would
> probably obligate any addition or change to the default key binding set
> to be adapted to all (or some) of these half a dozen profiles.
>
> So the more we have of them, the more work we add to our contributors.
> Or potential bugs when we forget to do that.
>

Additionally, I would like to point out that we need reproducible bug
recipes from bug reporters, and the best way to get them is something like
Emacs -Q and its defaults. It is unavoidable that offering profiles as
suggested is going to have a negative impact in that department. But
perhaps it can be controlled if we have a small number of profiles and said
profiles are easily chosen from the command line and  the bug reporting
instructions should updated accordingly.

I support this profiles idea. I suggest these to start:

- default, the default
- space-hippie, or space-pinhead, a reference to spacemacs and to Emacs'
hidden 70s origins
- doctor-doom, likewise for doom emacs, couldn't find anything particularly
clever here, sorry.

The idea are that the latter two are reasonably familiar to people
migrating from those distributions. Not sure about vi kebinds though, ugh...

João

>

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

^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-03 11:19                                             ` Eli Zaretskii
@ 2021-09-03 12:11                                               ` Dmitry Gutov
  2021-09-03 12:26                                                 ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 12:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

On 03.09.2021 14:19, Eli Zaretskii wrote:

>> Again you try to change any discussion of a change into an "addition".
>> Something that wouldn't change anything in the default behavior.
> 
> Because I think that's a much better way forward, in the long run.
> But if you want to insist on changing the defaults without the opt-in
> changes first, I guess we will be having this discussion many times in
> the future.

That is just side-stepping the question. There was never any 
disagreement about opt-in changes, and when it is feasible, we of course 
have taken that route.

>> What's so peculiar about changing the behavior that flies in the face of
>> existing practice in all programming languages out there? And which
>> causes confusion in new users?
>>
>> The way it is implemented made sense decades ago, but these days even
>> users who want tabs for indentation are surprised by Emacs behavior in
>> this area (because most of those users want 1 tab to mean 1 indentation
>> level).
> 
> You tried convincing in this before, and you failed.

That discussion is a great example of the problems I wrote about in this 
thread: we don't pay any attention to polls, hard statistics, articles 
and user posts (of which I produced plenty).

A few folks say "I don't like", and that's the end of it.

> IME, at least on
> my daytime job, source code produced by people these days with popular
> IDEs (not Emacs) includes TABs.

Does it include tabs in the same fashion as what is produced by Emacs? 
Which actually mixes tabs and spaces.

> So at least my experience disagrees
> with yours.  Which might explain why this change didn't happen.

I wasn't just listing my experience.

> Someone suggested to have "themes" in Emacs which could change the
> defaults of many settings in one simple command.  Why not invest the
> energy we waste in these endless discussions in making that happen?
> It at least would make the changes easier for newbies, if nothing
> else.

A few reasons. I don't really want to make Emacs more complex than it 
is. I usually strive to make the existing workflows simpler. There are 
only so many hours in a day.

Further: what kind of theme would include indent-tabs-mode set to nil? A 
theme called 'Sane Defaults'?

The users would need to find out about it somehow and then enable 
anyway, so what would make it different from having a custom option 
called indent-tabs-mode, which we have already?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 11:41                                   ` Eli Zaretskii
@ 2021-09-03 12:12                                     ` Dmitry Gutov
  2021-09-03 12:27                                       ` Eli Zaretskii
  2021-09-03 14:25                                     ` Gitlab Migration Daniel Fleischer
                                                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 12:12 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, rms, lokedhs, yantar92, emacs-devel, monnier

On 03.09.2021 14:41, Eli Zaretskii wrote:
> There, you have already a list of options to include in a suitably
> named "profile".  Why not add that to Emacs right now?

What would it be called?



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 12:11                                               ` João Távora
@ 2021-09-03 12:14                                                 ` Dmitry Gutov
  2021-09-03 12:33                                                   ` Eli Zaretskii
  2021-09-03 12:49                                                   ` Gitlab Migration João Távora
  2021-09-03 12:19                                                 ` Dmitry Gutov
  2021-09-03 12:30                                                 ` Eli Zaretskii
  2 siblings, 2 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 12:14 UTC (permalink / raw)
  To: João Távora
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Lars Ingebrigtsen, Eli Zaretskii, John Yates

On 03.09.2021 15:11, João Távora wrote:
> - default, the default
> - space-hippie, or space-pinhead, a reference to spacemacs and to Emacs' 
> hidden 70s origins
> - doctor-doom, likewise for doom emacs, couldn't find anything 
> particularly clever here, sorry.
> 
> The idea are that the latter two are reasonably familiar to people 
> migrating from those distributions. Not sure about vi kebinds though, ugh...

That's a little silly: people don't usually migrate off those 
distributions to vanilla. Or those that do, can already choose the 
settings they want to carry over.

Spacemacs and Doom don't differ that much between themselves either, not 
in basic behaviors.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 12:08                                             ` Dmitry Gutov
@ 2021-09-03 12:17                                               ` Eli Zaretskii
  0 siblings, 0 replies; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 12:17 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, larsi, john

> Cc: larsi@gnus.org, philipk@posteo.net, danflscr@gmail.com, rms@gnu.org,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, john@yates-sheets.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:08:03 +0300
> 
> On 03.09.2021 14:26, Eli Zaretskii wrote:
> > Figuring out these (and other) issues is indeed not trivial.  I still
> > hope someone will pick up the gauntlet, though.
> 
> Some of them can be figured by "someone" (e.g. the full resulting CUA 
> layout), but please don't dodge the fundamental questions.

Which are?...

> You reject the obvious and easy solution, after all.

I don't think it's easy at all, perhaps not even obvious.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 12:11                                               ` João Távora
  2021-09-03 12:14                                                 ` Dmitry Gutov
@ 2021-09-03 12:19                                                 ` Dmitry Gutov
  2021-09-03 12:30                                                 ` Eli Zaretskii
  2 siblings, 0 replies; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 12:19 UTC (permalink / raw)
  To: João Távora
  Cc: Philip K.,
	Daniel Fleischer, Richard Stallman, emacs-devel, Stefan Monnier,
	Lars Ingebrigtsen, Eli Zaretskii, John Yates

On 03.09.2021 15:11, João Távora wrote:
>     We should not forget that, by maintaining those profiles, we would
>     probably obligate any addition or change to the default key binding set
>     to be adapted to all (or some) of these half a dozen profiles.
> 
>     So the more we have of them, the more work we add to our contributors.
>     Or potential bugs when we forget to do that.
> 
> 
> Additionally, I would like to point out that we need reproducible bug 
> recipes from bug reporters, and the best way to get them is something 
> like Emacs -Q and its defaults. It is unavoidable that offering profiles 
> as suggested is going to have a negative impact in that department. But 
> perhaps it can be controlled if we have a small number of profiles and 
> said profiles are easily chosen from the command line and  the bug 
> reporting instructions should updated accordingly.

I honestly think that having a "CUA profile" alone (which seems to be 
the most requested one), would take up enough of our collective effort, 
that we wouldn't want to have many of them.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Representation of the Emacs userbase on emacs-devel
  2021-09-03 12:11                                               ` Dmitry Gutov
@ 2021-09-03 12:26                                                 ` Eli Zaretskii
  2021-09-04  1:32                                                   ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 12:26 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: philipk, danflscr, rms, emacs-devel, monnier, john

> Cc: philipk@posteo.net, rms@gnu.org, john@yates-sheets.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:11:44 +0300
> 
> On 03.09.2021 14:19, Eli Zaretskii wrote:
> 
> >> Again you try to change any discussion of a change into an "addition".
> >> Something that wouldn't change anything in the default behavior.
> > 
> > Because I think that's a much better way forward, in the long run.
> > But if you want to insist on changing the defaults without the opt-in
> > changes first, I guess we will be having this discussion many times in
> > the future.
> 
> That is just side-stepping the question.

Which question?

We are, I hope, interested mainly in making Emacs evolve and adapt to
the changing times and preferences.  I consider the way of introducing
changes as optional first to be a better way towards that goal,
including the goal to change the defaults.  And I explained in so many
words why and how.  How is that side-stepping the issue at hand?

> > You tried convincing in this before, and you failed.
> 
> That discussion is a great example of the problems I wrote about in this 
> thread: we don't pay any attention to polls, hard statistics, articles 
> and user posts (of which I produced plenty).
> 
> A few folks say "I don't like", and that's the end of it.

Show me a project where things are different, where the lead
developers cannot say "I don't like" (with arguments, which you forget
to mention, or prefer to dismiss or disregard, but they are still
there), and that's it.  This is how Free Software projects are being
developed, at least IME.  Emacs is not an outlier, it's right there in
the mainstream.

> > IME, at least on
> > my daytime job, source code produced by people these days with popular
> > IDEs (not Emacs) includes TABs.
> 
> Does it include tabs in the same fashion as what is produced by Emacs? 
> Which actually mixes tabs and spaces.

Why does it matter?  If we'd make the default use only TABs, would you
agree then?

> > So at least my experience disagrees
> > with yours.  Which might explain why this change didn't happen.
> 
> I wasn't just listing my experience.

Neither was I.  Anyone who'd look at the output of those IDEs will see
it, you don't need my "experience" to do that.  It's a fact.

> > Someone suggested to have "themes" in Emacs which could change the
> > defaults of many settings in one simple command.  Why not invest the
> > energy we waste in these endless discussions in making that happen?
> > It at least would make the changes easier for newbies, if nothing
> > else.
> 
> A few reasons. I don't really want to make Emacs more complex than it 
> is. I usually strive to make the existing workflows simpler. There are 
> only so many hours in a day.
> 
> Further: what kind of theme would include indent-tabs-mode set to nil? A 
> theme called 'Sane Defaults'?

Then I guess you won't be working on this any time soon.  Which is
perfectly okay; I hope someone else will.

> The users would need to find out about it somehow and then enable 
> anyway, so what would make it different from having a custom option 
> called indent-tabs-mode, which we have already?

The difference is that you need to choose among a small number of
themes, instead of among many dozens of individual options.  It makes
the customization simpler.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 12:12                                     ` Dmitry Gutov
@ 2021-09-03 12:27                                       ` Eli Zaretskii
  2021-09-03 12:32                                         ` Dmitry Gutov
  0 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 12:27 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: philipk, danflscr, rms, lokedhs, yantar92, emacs-devel, monnier

> Cc: philipk@posteo.net, yantar92@gmail.com, lokedhs@gmail.com,
>  danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:12:08 +0300
> 
> On 03.09.2021 14:41, Eli Zaretskii wrote:
> > There, you have already a list of options to include in a suitably
> > named "profile".  Why not add that to Emacs right now?
> 
> What would it be called?

I don't know, but I don't think the name is the main issue.  The main
issue is to identify the settings many people would like to change,
then try to group them in some reasonable way.



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 12:11                                               ` João Távora
  2021-09-03 12:14                                                 ` Dmitry Gutov
  2021-09-03 12:19                                                 ` Dmitry Gutov
@ 2021-09-03 12:30                                                 ` Eli Zaretskii
  2021-09-03 15:49                                                   ` João Távora
  2 siblings, 1 reply; 525+ messages in thread
From: Eli Zaretskii @ 2021-09-03 12:30 UTC (permalink / raw)
  To: João Távora
  Cc: philipk, danflscr, rms, emacs-devel, monnier, dgutov, larsi, john

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 3 Sep 2021 13:11:41 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, "Philip K." <philipk@posteo.net>, 
> 	Daniel Fleischer <danflscr@gmail.com>, Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>, 
> 	John Yates <john@yates-sheets.org>
> 
> Additionally, I would like to point out that we need reproducible bug recipes from bug reporters, and the best
> way to get them is something like Emacs -Q and its defaults. It is unavoidable that offering profiles as
> suggested is going to have a negative impact in that department. But perhaps it can be controlled if we have
> a small number of profiles and said profiles are easily chosen from the command line and  the bug reporting
> instructions should updated accordingly.

I don't think this is a significant problem.  We could add the active
"profile(s)" to the report by report-emacs-bug, and that would take
care of reproducing the issues that don't happen in "emacs -Q".



^ permalink raw reply	[flat|nested] 525+ messages in thread

* Re: Gitlab Migration
  2021-09-03 12:27                                       ` Eli Zaretskii
@ 2021-09-03 12:32                                         ` Dmitry Gutov
  2021-09-03 12:45                                           ` Eli Zaretskii
  0 siblings, 1 reply; 525+ messages in thread
From: Dmitry Gutov @ 2021-09-03 12:32 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: philipk, danflscr, rms, lokedhs, yantar92, emacs-devel, monnier

On 03.09.2021 15:27, Eli Zaretskii wrote:
>>> There, you have already a list of options to include in a suitably
>>> named "profile".  Why not add that to Emacs right now?
>> What would it be called?
> I don't know, but I don't think the name is the main issue.  The main
> issue is to identify the settings many people would like to change,
> then try to group them in some reasonable way.

It *is* an issue.

The problem with variables with indent-tabs-mode and 
r