Re: Gitlab Migration

Re: Gitlab Migration

[koder33]

hi. Just come here to drop a brillant idea as one more option:  Write your own server-client app.

Pros:

* Really not need to go beyond above 3-5k LOC.
* Its needs written with C language. Available eveywhere.
* No JS problem from the beginning.
* No spam message or spam account.
* No needs for an e-mail account.
* Client part as cli or basic curses/dialog like tui. Available everwhere, even a system composed only kernel + busybox.
* Its generic. Available for everyone/every other project to host own project.
* Offers 100% control w.r.t security, privacy.
* Low maintenance burden for admins, project leaders.
* Low maintenance burden for its own developer.
* Easy to use for user. Single click/press to fork, make patch, MR, commit ...
* Feel free to use git, hg ... as backend. Or rool your own.
* So on.
* Really so on.

Cons:

* Someone has to write.
* No fancy, no loby, no eyecandy.

Re: Gitlab Migration

[koder33]

Just reply to my own post for completeness.

"Client part" can be implemented as an add-on/module in emacs itself; even with lisp.

"Server part" just provide a bunch of api to communicate.

Feel free to choose an app layer protocol (http, https, others ...) for communication;
 even raw ip socket as they best fit.

BTW: How about other projects under the GNU/FSF umbrella wrt "forge" things.

How about unifying all member project into one 'server'/'server api' then use emacs with mentioned add-on(s) as client to manage everything wrt forge.

One add-on for e-mail things, one for vcs/scm backend and one for instant messaging :P

Sounds crazy? Posting just FYI. If counts as noise pardon me.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Friday, September 10th, 2021 at 9:53 PM, koder33  wrote:

> hi. Just come here to drop a brillant idea as one more option: Write your own server-client app.
>
> Pros:
>
> -   Really not need to go beyond above 3-5k LOC.
> -   Its needs written with C language. Available eveywhere.
> -   No JS problem from the beginning.
> -   No spam message or spam account.
> -   No needs for an e-mail account.
> -   Client part as cli or basic curses/dialog like tui. Available everwhere, even a system composed only kernel + busybox.
> -   Its generic. Available for everyone/every other project to host own project.
> -   Offers 100% control w.r.t security, privacy.
> -   Low maintenance burden for admins, project leaders.
> -   Low maintenance burden for its own developer.
> -   Easy to use for user. Single click/press to fork, make patch, MR, commit ...
> -   Feel free to use git, hg ... as backend. Or rool your own.
> -   So on.
> -   Really so on.
>
>     Cons:
> -   Someone has to write.
> -   No fancy, no loby, no eyecandy.

Re: Gitlab Migration

[Simon Pugnet]

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

Stefan Kangas <stefan@marxist.se> writes:

> 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

Hi all,

I'm not sure if this is of interest but I just thought I'd throw this
into the discussion:
https://blog.polaris64.net/post/could-emacs-have-a-set-up-wizard/.

I thought about a "wizard" which would help newcomers to choose from a
set of profiles in a simple manner, and this blog post details a little
proof-of-concept I came up with. The idea was that it would keep out of
the way as much as possible so that existing users could easily ignore
it or disable the entry on the splash screen if necessary, however it
would still be prominent enough for newcomers to see it.

Best regards,
Simon

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

Gitlab Migration

[Daniel Fleischer]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Yuchen Pei]

[-- 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 --]

Re: Gitlab Migration

[Werner LEMBERG]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[dick]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[dick]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Alexander Adolf]

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

Re: Gitlab Migration

[Alexander Adolf]

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/

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

>>
>

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Jim Porter]

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/

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

> 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"?

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Arthur Miller]

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?

Re: Gitlab Migration

[Dmitry Gutov]

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

Re: Gitlab Migration

[Arthur Miller]

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. 

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Po Lu]

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?

Re: Gitlab Migration

[Arthur Miller]

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?

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Po Lu]

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

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[Daniel Fleischer]

[-- 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*

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Tim Cross]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Arthur Miller]

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

Re: Gitlab Migration

[Arthur Miller]

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

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Tim Cross]

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

Re: Gitlab Migration

[Arthur Miller]

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. 

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Maxim Nikulin]

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.

Re: Gitlab Migration

[john muhl]

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

Re: Gitlab Migration

[Greg Farough]

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

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[Daniel Martín]

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.

Re: Gitlab Migration

[Tassilo Horn]

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

Re: Gitlab Migration

[Daniel Martín]

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.

Re: Gitlab Migration

[Clément Pit-Claudel]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[Daniel Brooks]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Daniel Brooks]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Óscar Fuentes]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Yuri Khan]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Yuri Khan]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Óscar Fuentes]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Daniel Brooks]

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

Re: Gitlab Migration

[Stefan Monnier]

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

Re: Gitlab Migration

[tomas]

[-- 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 --]

Re: Gitlab Migration

[Dmitry Gutov]

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?

Re: Gitlab Migration

[Clément Pit-Claudel]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Clément Pit-Claudel]

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.

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[Andreas Schwab]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Tim Cross]

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?

Re: Gitlab Migration

[Jean-Christophe Helary]

[-- 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 --]

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Arthur Miller]

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.

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Daniel Fleischer]

[-- 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*

Re: Gitlab Migration

[Tim Cross]

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. 

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[André A. Gomes]

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"

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Eli Zaretskii]

> 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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Sean Whitton]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Drew DeVault]

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

Re: Gitlab Migration

[Daniel Martín]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Drew DeVault]

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

Re: Gitlab Migration

[Dmitry Gutov]

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?

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Drew DeVault]

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!

Re: Gitlab Migration

[Theodor Thornhill]

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.

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Theodor Thornhill]

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.

Re: Gitlab Migration

[theo]

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

Re: Gitlab Migration

[Tassilo Horn]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[João Távora]

[-- 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 --]

Re: Gitlab Migration

[João Távora]

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

Re: Gitlab Migration

[David Engster]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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?

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Drew DeVault]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Theodor Thornhill]

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!

Re: Gitlab Migration

[Drew DeVault]

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!

Re: Gitlab Migration

[Daniel Fleischer]

[-- 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*

Re: Gitlab Migration

[Drew DeVault]

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

Re: Gitlab Migration

[Jean-Christophe Helary]

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

Re: Gitlab Migration

[Alan Third]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Jean-Christophe Helary]

[-- 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 --]

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Drew DeVault]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Dmitry Gutov]

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?

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Theodor Thornhill]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Daniel Fleischer]

[-- 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*

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Theodor Thornhill]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Dmitry Gutov]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Daniel Fleischer]

[-- 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*

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Elias Mårtenson]

[-- 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 --]

Re: Gitlab Migration

[Ihor Radchenko]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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?

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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 
require-final-newline is they affect Emacs's behavior in ways that 
aren't apparent to a new user, or to a beginner programmer. And then 
they can cause problems for the teammates who aren't even using Emacs.

Having a profile unassumingly called "Dmitry Gutov's Preferences" (who 
would want to enable THAT, right?), which would need to be enabled to 
avoid these issues, is a usability problem.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:32:10 +0300
> Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, lokedhs@gmail.com,
>  yantar92@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> 
> 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.

It's an issue, but not the most important or urgent one.

> The problem with variables with indent-tabs-mode and 
> require-final-newline is they affect Emacs's behavior in ways that 
> aren't apparent to a new user, or to a beginner programmer. And then 
> they can cause problems for the teammates who aren't even using Emacs.
> 
> Having a profile unassumingly called "Dmitry Gutov's Preferences" (who 
> would want to enable THAT, right?), which would need to be enabled to 
> avoid these issues, is a usability problem.

I'd start by collecting the relevant settings.  E.g., if those 4 are
the only ones, or close to that, then perhaps a single profile named
"convenience" or somesuch would be enough.  But I suspect there are
many more, so we'd need to divide them into groups, and then name each
group accordingly.

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:45, Eli Zaretskii wrote:
>> The problem with variables with indent-tabs-mode and
>> require-final-newline is they affect Emacs's behavior in ways that
>> aren't apparent to a new user, or to a beginner programmer. And then
>> they can cause problems for the teammates who aren't even using Emacs.
>>
>> Having a profile unassumingly called "Dmitry Gutov's Preferences" (who
>> would want to enable THAT, right?), which would need to be enabled to
>> avoid these issues, is a usability problem.
> I'd start by collecting the relevant settings.  E.g., if those 4 are
> the only ones, or close to that, then perhaps a single profile named
> "convenience" or somesuch would be enough.  But I suspect there are
> many more, so we'd need to divide them into groups, and then name each
> group accordingly.

A private email reminded me of a certain suggestion that has been made 
in this area. And here is a possible twist on the proposal:

What if we do introduce the "profiles" feature, *and* we change our 
practice to alter the defaults more easily as well? Including radical, 
mutinous ones, like indent-tabs-mode -> nil. Not all of them, of course, 
but with more of an eye toward being useful for new users (violent 
discussions about the default values will continue, but will sometimes 
results in changes, too).

And to avoid the problems with Emacs's default moving forward, we 
introduce a profile called "Good Old Days" which the folks who prefer 
things to generally stay the same, would enable, just once. Going 
forward, every time we change some default, we would consider adding the 
previous value to that profile. Or even do that automatically.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, lokedhs@gmail.com,
>  yantar92@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 16:26:41 +0300
> 
> What if we do introduce the "profiles" feature, *and* we change our 
> practice to alter the defaults more easily as well? Including radical, 
> mutinous ones, like indent-tabs-mode -> nil. Not all of them, of course, 
> but with more of an eye toward being useful for new users (violent 
> discussions about the default values will continue, but will sometimes 
> results in changes, too).
> 
> And to avoid the problems with Emacs's default moving forward, we 
> introduce a profile called "Good Old Days" which the folks who prefer 
> things to generally stay the same, would enable, just once. Going 
> forward, every time we change some default, we would consider adding the 
> previous value to that profile. Or even do that automatically.

This was discussed, but I don't think it flied.  maybe it will one
day, who knows?

Of course, given a profile that becomes the default, the "good old
days" counterpart of it is almost trivial to come up with.

Re: Gitlab Migration

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> What if we do introduce the "profiles" feature, *and* we change our
> practice to alter the defaults more easily as well? Including radical,
> mutinous ones, like indent-tabs-mode -> nil. Not all of them, of
> course, but with more of an eye toward being useful for new users
> (violent discussions about the default values will continue, but will
> sometimes results in changes, too).

1+

It seems to me that the current practice ends up disappointing both
those who want to change the default (everything is stale) and
traditional users (minor annoyances are introduced all the time).

If it were possible for the former to fix how they want the defaults to
be by adding something like

   (load-theme 'emacs-27)

to their init, they wouldn't have to fight against every minor change,
while at the same time making it easier to argue for incremental changes
for the other users.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> If it were possible for the former to fix how they want the defaults to
> be by adding something like
>
>    (load-theme 'emacs-27)
>
> to their init, they wouldn't have to fight against every minor change,
> while at the same time making it easier to argue for incremental changes
> for the other users.

Yes, I can certainly see that as a possible good feature.

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>    (load-theme 'emacs-27)
>>
>> to their init, they wouldn't have to fight against every minor change,
>> while at the same time making it easier to argue for incremental changes
>> for the other users.
>
> Yes, I can certainly see that as a possible good feature.

(But I don't think that'll get rid of any complaints, really -- there'll
be people going "you changed the defaults on this, and that was good,
but you changed this other thing, too, and THAT"S THE WORST CRIME
AGAINST HUMANITY EVER, and I want the first thing, but not the second
thing, so I can't use (load-theme 'emacs-27), so you suck, and I'm now
switching to vim forever (after posting on Hacker News about how much
you suck)".  That's just people being people.)

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

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 18:11, Lars Ingebrigtsen wrote:
> (But I don't think that'll get rid of any complaints, really -- there'll
> be people going "you changed the defaults on this, and that was good,
> but you changed this other thing, too, and THAT"S THE WORST CRIME
> AGAINST HUMANITY EVER, and I want the first thing, but not the second
> thing, so I can't use (load-theme 'emacs-27), so you suck, and I'm now
> switching to vim forever (after posting on Hacker News about how much
> you suck)".  That's just people being people.)

That's why "nobody is unhappy" is a bad criterion for making changes.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> That's why "nobody is unhappy" is a bad criterion for making changes.

Indeed.  For instance, there are still people livid about making
line-move-visual the default, over a decade afterwards, but that was the
right decision, anyway.

On the other hand, it is pretty annoying to have things change under
your feet, so it's a balancing act.

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

Re: Gitlab Migration

[Juri Linkov]

> If it were possible for the former to fix how they want the defaults to
> be by adding something like
>
>    (load-theme 'emacs-27)

Its contents could look like the node "Antinews" in the Info manual,
but with code that reverts all release changes.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  danflscr@gmail.com,  rms@gnu.org,
>   lokedhs@gmail.com,  yantar92@gmail.com,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 03 Sep 2021 19:08:35 +0300
> 
> > If it were possible for the former to fix how they want the defaults to
> > be by adding something like
> >
> >    (load-theme 'emacs-27)
> 
> Its contents could look like the node "Antinews" in the Info manual,
> but with code that reverts all release changes.

Assuming you are serious, no: "Antinews" mentions only a small
fraction of changes called out in NEWS.

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 22:13, Eli Zaretskii wrote:
>> From: Juri Linkov<juri@linkov.net>
>> Cc: Dmitry Gutov<dgutov@yandex.ru>,danflscr@gmail.com,rms@gnu.org,
>>    lokedhs@gmail.com,yantar92@gmail.com,emacs-devel@gnu.org,
>>    monnier@iro.umontreal.ca,  Eli Zaretskii<eliz@gnu.org>
>> Date: Fri, 03 Sep 2021 19:08:35 +0300
>>
>>> If it were possible for the former to fix how they want the defaults to
>>> be by adding something like
>>>
>>>     (load-theme 'emacs-27)
>> Its contents could look like the node "Antinews" in the Info manual,
>> but with code that reverts all release changes.
> Assuming you are serious, no: "Antinews" mentions only a small
> fraction of changes called out in NEWS.

And vice versa: I would expect at least some changes in defaults to go 
uncontested, then they don't need to go into the good-old-days profile.

Though whenever somebody objects -- in they go.

Re: Gitlab Migration

[Daniel Fleischer]

Eli Zaretskii [2021-09-03 Fri 14:41] wrote:

> There, you have already a list of options to include in a suitably
> named "profile".  Why not add that to Emacs right now?

I can start compiling a list of variables and customizations, by groups,
with some documentation hints. Probably a discussion about the variables
and default values will indicate if a single profile is enough or not.

-- 

Daniel Fleischer

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,  rms@gnu.org,
>   lokedhs@gmail.com,  yantar92@gmail.com,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca
> Date: Fri, 03 Sep 2021 17:25:12 +0300
> 
> I can start compiling a list of variables and customizations, by groups,
> with some documentation hints.

Please do, and thanks.

> Probably a discussion about the variables and default values will
> indicate if a single profile is enough or not.

Yes, it will all be easier and more practical when we have a list to
work with.

Re: Gitlab Migration

[Daniel Fleischer]

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

Starting simple, with the following four areas:

;; Convenient
(setq scroll-preserve-screen-position t)
(setq visual-order-cursor-movement t)
(setq-default tab-width 4)
(global-auto-revert-mode)
(auto-save-visited-mode)
(indent-tabs-mode -1)

;; Compatibility with other editors
(electric-indent-mode)
(electric-pair-mode)
(cua-mode)

;; Session
(desktop-save-mode)

;; Visual
(tool-bar-mode -1)
(global-visual-line-mode)
(show-paren-mode)


Some questions:

1. Do we want to split the audience to writers and programmers because
   it impacts the implementation and the messaging as well.

2. Do we also install popular and relevant Elpa packages as part of the
   profile setup or do we cross the line at variable setting? what about
   keybindings?


--
Daniel Fleischer

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 11:02, Daniel Fleischer wrote:
> (setq-default tab-width 4)

Just a heads-up: this one is kinda dangerous because if you view and 
edit files made with default value of tab-width, and they have tabs in 
them (like a lot of files in the Emacs repo), they will end up looking 
wrong. And if you then edit them and perhaps reindent, the patches can 
look wrong to others.

I could be wrong, but last I checked there was either no consensus on 
this value among editors, or 8 was still popular enough.

global-visual-line-mode seems questionable as well -- I don't remember 
seeing this kind of behavior in other coding editors, which seems to be 
the aim of this profile. At least not by default.

The rest of the list looks good (I'd put the cua-mode setting into a 
different profile, but that can be a part of a larger effort).

Thanks!

Re: Gitlab Migration

[Daniel Fleischer]

Dmitry Gutov [2021-09-04 Sat 13:59] wrote:

> global-visual-line-mode seems questionable as well -- I don't remember seeing this kind of behavior in other coding
> editors, which seems to be the aim of this profile. At least not by default.

Now it really depends on who we compare with; if we go with the
"programmers" profile then one can compare with Vim, VScode and Sublime
Text.  The first two do not wrap and the last one does.  Any other
editor we should examine for deaults?


-- 

Daniel Fleischer

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 14:37, Daniel Fleischer wrote:
> Dmitry Gutov [2021-09-04 Sat 13:59] wrote:
> 
>> global-visual-line-mode seems questionable as well -- I don't remember seeing this kind of behavior in other coding
>> editors, which seems to be the aim of this profile. At least not by default.
> Now it really depends on who we compare with; if we go with the
> "programmers" profile then one can compare with Vim, VScode and Sublime
> Text.  The first two do not wrap and the last one does.  Any other
> editor we should examine for deaults?

Now that I looked, Sublime does have the option to Word Wrap, but it 
seems to be unchecked by default?

Another popular option is Intellij IDEA (no word-wrap by default either, 
as far as I can see). Neither does Atom.

There are also Eclipse and Netbeans, and some others, but AFAIK VS Code 
and IDEA hold the popularity crown these days.

visual-line-mode also has a side-effect of having "simple editing 
commands to act on visual lines" instead of logical ones, so that 
kill-line only kills a part of the line. I couldn't find whether Sublime 
has any similar commands where we could compare the effect.

Re: Gitlab Migration

[Daniel Fleischer]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Now that I looked, Sublime does have the option to Word Wrap, but it seems to be unchecked by default?

Actually it's "auto": wrap for text, non-wrap for programming. 

> Another popular option is Intellij IDEA (no word-wrap by default either, as far as I can see). Neither does Atom.

So it looks like for programming the default is no word-wrap. 


-- 

Daniel Fleischer

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Sat, 04 Sep 2021 17:10:17 +0300
> 
> So it looks like for programming the default is no word-wrap. 

What do they do instead? truncate?

Re: Gitlab Migration

[Daniel Fleischer]

Eli Zaretskii <eliz@gnu.org> writes:

> What do they do instead? truncate?

Either start to horizontal scroll or soft-wrap in the middle of words.

-- 

Daniel Fleischer

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Sat, 04 Sep 2021 17:22:29 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What do they do instead? truncate?
> 
> Either start to horizontal scroll or soft-wrap in the middle of words.

Horizontal scroll == truncate+horizontal-scroll-bar-mode, right?
And soft-wrap == continuation lines, right?
Which one is more popular?

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 17:10, Daniel Fleischer wrote:
> Actually it's "auto": wrap for text, non-wrap for programming.

Sounds sensible.

Re: Gitlab Migration

[Stefan Kangas]

Daniel Fleischer <danflscr@gmail.com> writes:

> > Another popular option is Intellij IDEA (no word-wrap by default either, as far as I can see). Neither does Atom.
>
> So it looks like for programming the default is no word-wrap.

So there should be a hook turning wrapping off in `prog-mode', right?

Re: Gitlab Migration

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04.09.2021 14:37, Daniel Fleischer wrote:
>> Dmitry Gutov [2021-09-04 Sat 13:59] wrote:
>> 
>>> global-visual-line-mode seems questionable as well -- I don't remember seeing this kind of behavior in other coding
>>> editors, which seems to be the aim of this profile. At least not by default.
>> Now it really depends on who we compare with; if we go with the
>> "programmers" profile then one can compare with Vim, VScode and Sublime
>> Text.  The first two do not wrap and the last one does.  Any other
>> editor we should examine for deaults?
>
> Now that I looked, Sublime does have the option to Word Wrap, but it
> seems to be unchecked by default?
>
> Another popular option is Intellij IDEA (no word-wrap by default
> either, as far as I can see). Neither does Atom.
>
> There are also Eclipse and Netbeans, and some others, but AFAIK VS
> Code and IDEA hold the popularity crown these days.
>
> visual-line-mode also has a side-effect of having "simple editing
> commands to act on visual lines" instead of logical ones, so that
> kill-line only kills a part of the line. I couldn't find whether
> Sublime has any similar commands where we could compare the effect.

If this is about replicating what other popular text editors do, why not
simply create emulation modes? sublime-mode, vs-code-mode, etc. Emacs
has a long tradition doing that (see the successive Vi(m) emulation
modes.)

I'll mention that the proposed configuration theming has an important
side-effect: in practice, the user no longer is using Emacs, but a
customization that makes difficult to provide support and benefiting
from existing published resources. An example: if someone posts a
question on help-emacs, the first thing I need to know if he is using
one of those config themes; if the answer is "yes", most likely I will
unable to assist him because I must know the theme and adapt my
instructions in accordance.

IMAO all those arguments about newcomers being turned off by weird
defaults is overblown. I agree that several defaults could be better,
but Emacs should not bend over to compete with the low-effort,
install-and-run editors. IMHO Emacs target audience should de the
high-effort, high-productivity individuals. Things like C-x are not so
important on that context.

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 17:33, Óscar Fuentes wrote:

> If this is about replicating what other popular text editors do, why not
> simply create emulation modes? sublime-mode, vs-code-mode, etc. Emacs
> has a long tradition doing that (see the successive Vi(m) emulation
> modes.)

I think it's more about being a little less alien right away (which is 
where a lot of first users will bounce off), and about showing off some 
of the little niceties that others have but we have disabled (to make 
first good impression), like show-paren and the electric modes.

And having some better defaults, where we for some reasons cannot 
incorporate them in the stock configuration.

> I'll mention that the proposed configuration theming has an important
> side-effect: in practice, the user no longer is using Emacs, but a
> customization that makes difficult to provide support and benefiting
> from existing published resources. An example: if someone posts a
> question on help-emacs, the first thing I need to know if he is using
> one of those config themes; if the answer is "yes", most likely I will
> unable to assist him because I must know the theme and adapt my
> instructions in accordance.

One idea was that report-emacs-bug would mention the enabled profiles. 
Some assistance for help ports, and for other means of bug reporting 
(other bug trackers, e.g. for third-party packages) could be added too.

> IMAO all those arguments about newcomers being turned off by weird
> defaults is overblown. I agree that several defaults could be better,
> but Emacs should not bend over to compete with the low-effort,
> install-and-run editors. IMHO Emacs target audience should de the
> high-effort, high-productivity individuals.

I disagree with that: Emacs can fit lots of different users.

> Things like C-x are not so
> important on that context.

...but I would prefer to move the cua-mode setting to a separate profile 
too. Or have it like a separate checkbox in the wizard, or similar.

Re: Gitlab Migration

[Stefan Monnier]

>> (setq-default tab-width 4)
[...]
> I could be wrong, but last I checked there was either no consensus on this
> value among editors, or 8 was still popular enough.

My religion tells me that $DEITY has clearly specified TABs to have
a width of 8.  But of late, I've found heretics using 4 to be arguably
more frequent than the true believers.

In Python they survive by using an indentation style that makes the TAB
width non-significant (i.e. every line is indented exclusively with
TABs).


        Stefan

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 16:46, Stefan Monnier wrote:
> My religion tells me that $DEITY has clearly specified TABs to have
> a width of 8.  But of late, I've found heretics using 4 to be arguably
> more frequent than the true believers.
> 
> In Python they survive by using an indentation style that makes the TAB
> width non-significant (i.e. every line is indented exclusively with
> TABs).

I've seen (and had participated in) this trend as well, but AFAICT there 
is still no consensus on the subject among editors' default settings.

Some can correct me if I'm wrong.

And I guess one thing to worry about is as long as this setting is only 
changed in a profile but not in stock Emacs (which seems infeasible), we 
are fragmenting the user base and risk worse interoperability for 
contributors on Emacs-related projects.

Which, I don't know, in the end might only matter for patches sent for 
Emacs itself (the rest of Elisp projects use spaces).

Re: Gitlab Migration

[Augusto Stoffel]

On Sat,  4 Sep 2021 at 09:46, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> (setq-default tab-width 4)
> [...]
>> I could be wrong, but last I checked there was either no consensus on this
>> value among editors, or 8 was still popular enough.
>
> My religion tells me that $DEITY has clearly specified TABs to have
> a width of 8.  But of late, I've found heretics using 4 to be arguably
> more frequent than the true believers.
>
> In Python they survive by using an indentation style that makes the TAB
> width non-significant (i.e. every line is indented exclusively with
> TABs).
>
>
>         Stefan

That's true, but the Python scriptures basically instruct you to set
`indent-tabs-mode' to nil:

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Re: Gitlab Migration

[João Távora]

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

On Sat, Sep 4, 2021, 09:03 Daniel Fleischer <danflscr@gmail.com> wrote:

> Starting simple, with the following four...


Thank you for this indexing effort.

2. Do we also install popular and relevant Elpa packages as part of the
>    profile setup or do we cross the line at variable setting? what about
>    keybindings?
>

Yes.  I think we want the list to be more ambitious. For now, it'd be nice
to see, at a glance, what we would ideally like to configure via profile.
Then we can narrow down to what we are realistically and practically
capable of doing. And, in any case, no one profile is obliged to set all
the things that it can set.

I think the separation into categories is very good. E.g. If there is an
"external package" category, it is easier to tell if a particular profile
installs packages, i.e potentially needs internet.

A "global kebinds" category is probably also warranted.  cua-mode should
fall into that, I think. Viper-mode would also. Curiously, evil-mode would
fall into both "external package" and "keybindings". Maybe we need tags...

João

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> indent-tabs-mode -> nil (of course)

It's also make Emacs users wealthier:

https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

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

Re: Gitlab Migration

[Daniel Fleischer]

Lars Ingebrigtsen [2021-09-05 Sun 09:47] wrote:

> It's also make Emacs users wealthier:
>
> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

Obviously causation.

-- 

Daniel Fleischer

Re: Gitlab Migration

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> indent-tabs-mode -> nil (of course)
>
> It's also make Emacs users wealthier:
>
> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

Well, it also says that there are as many programmers using tabs as
using spaces, which goes against some asseverations made on this thread.
That's based on a survey made by Stackoverflow, so we can assume that
old farts writing COBOL nine to five at $BIGBANK are not skewing the
results.

Re: Gitlab Migration

[Dmitry Gutov]

On 05.09.2021 21:38, Óscar Fuentes wrote:
> Well, it also says that there are as many programmers using tabs as
> using spaces, which goes against some asseverations made on this thread.

I don't think it says exactly that, though the difference is much less 
pronounced there that in my previous analysis. Though some previous 
survey result did say that, see my response here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322#137

And the whole thread, if you like.

> That's based on a survey made by Stackoverflow, so we can assume that
> old farts writing COBOL nine to five at $BIGBANK are not skewing the
> results.

To try to reconcile this with the main analysis I used 
(http://sideeffect.kr/popularconvention/#javascript, based on Github 
code), I can either hypothesize that there is a silent crowd that uses 
spaces but doesn't participate in surveys, or that people working on 
closed-source projects use tabs more than the others (?).

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Stefan Kangas]

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

Re: Gitlab Migration

[Richard Stallman]

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

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

When Guy Steele worked out the Emacs command set, he chose C-x
for "extended".  That is natural and easy to remember.  It is true
that C-w for kill-region is not particularly natural, but at least
one of the two bindings makes sense.

Swap them, and neither of them would make sense.

As for why we didn't anticipate that someone else would use C-x to
mean kill-region, that's because we had no relationship with SRI.
If we had had one, we could have asked them to send a precognitive
to help us.

I wouldn't mind offering easy options to replace groups of basic
key bindings, such as the CUA bindings and C-x.  This could be
a feature in a set-up wizard.

It is important for these options to work together, when they
don't conflict.  So if you enable the undo-redo bindings
and the CUA bindings at once, you'd get both changes.

I don't see any point in supporting the sort of profile that replaces
many bindings en masse.  That is less flexible.

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

Re: Gitlab Migration

[Richard Stallman]

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

  > To give a concrete example, the kill ring is objectively better/more
  > powerful than the undo/redo you find in other text editors.

I see how it makes sense to compare undo/redo with Emacs undo, but how
does it make sense to compare undo/redo with the kill ring?  They do
different jobs.

I think undo/redo instead of undo-only might be an improvement in
Emacs, and might not be hard to get used to as a change -- if only we
can find a key binding for redo.  I know we had a discussion of
this before.

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

Re: Gitlab Migration

[Dmitry Gutov]

On 05.09.2021 06:44, Richard Stallman wrote:
> I think undo/redo instead of undo-only might be an improvement in
> Emacs, and might not be hard to get used to as a change -- if only we
> can find a key binding for redo.  I know we had a discussion of
> this before.

Let me do a recap. We proposed the keys that a reasonably popular 11 
year old package called undo-tree uses: 'C-?' and 'M-_'.

You replied that those seem inconvenient because C-? is not available on 
ttys, and both C-? and M-_ require two shift keys.

Others replied later that users generally expect 'redo' to require one 
more modifier than 'undo'. In graphical Emacs, it can work out to having 
'C-/' call 'undo', then one can additionally hold down the Shift key to 
the right of '/', calling 'redo' with the resulting 'C-?'.

Alas, there would be no such easy transition in terminal Emacs, but 
other than that, requiring an extra modifier key is not inherently a 
problem. The user should be able to switch between C-- and M-S-- and 
back without too much trouble.

In the same discussion T.V. Raman mentioned that he has bound 
'undo-redo' to 'C-x C-u', to stay close to 'C-x u', another default 
binding for 'undo'.

'C-x C-u' is unfortunately occupied, but it's a disabled command, so 
maaaybe we could take over the binding? Or use 'C-x U'.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05.09.2021 06:44, Richard Stallman wrote:
>> I think undo/redo instead of undo-only might be an improvement in
>> Emacs, and might not be hard to get used to as a change -- if only we
>> can find a key binding for redo.  I know we had a discussion of
>> this before.
>
> Let me do a recap. We proposed the keys that a reasonably popular 11 year old
> package called undo-tree uses: 'C-?' and 'M-_'.
>
> You replied that those seem inconvenient because C-? is not available on ttys,
> and both C-? and M-_ require two shift keys.
>
> Others replied later that users generally expect 'redo' to require one more
> modifier than 'undo'. In graphical Emacs, it can work out to having 'C-/' call
> 'undo', then one can additionally hold down the Shift key to the right of '/',
> calling 'redo' with the resulting 'C-?'.
>
> Alas, there would be no such easy transition in terminal Emacs, but other than
> that, requiring an extra modifier key is not inherently a problem. The user
> should be able to switch between C-- and M-S-- and back without too much
> trouble.
>
> In the same discussion T.V. Raman mentioned that he has bound 'undo-redo' to
> 'C-x C-u', to stay close to 'C-x u', another default binding for 'undo'.
>
> 'C-x C-u' is unfortunately occupied, but it's a disabled command, so maaaybe we
> could take over the binding? Or use 'C-x U'.

Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)

V is next to c, so all prefixes follow next to each other x,c and v.

Re: Gitlab Migration

[Stefan Kangas]

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

> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)

C-v is bound to scroll-up-command.

Re: Gitlab Migration

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>
> C-v is bound to scroll-up-command.
I know, but scroll-up can be rebound .... I use M-v for scroll

Re: Gitlab Migration

[Philip Kaludercic]

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

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>>
>> C-v is bound to scroll-up-command.
> I know, but scroll-up can be rebound .... I use M-v for scroll

So where would you rebind scroll-down-command?

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Stefan Kangas <stefan@marxist.se> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>>>
>>> C-v is bound to scroll-up-command.
>> I know, but scroll-up can be rebound .... I use M-v for scroll
>
> So where would you rebind scroll-down-command?

I have M-v scroll/M-p scroll up/down by line, M-S-v/M-S-p by page. I am using C-v
and C-z as prefixes already, for like two years or so.

Hitting alt is slightly less comfortable than hitting ctrl, especially on
europian keyboards since we don't have right alt (it is alt-gr), but it is not
so bad. I am quite ok with it.

Re: Gitlab Migration

[Yuri Khan]

On Tue, 7 Sept 2021 at 11:57, Arthur Miller <arthur.miller@live.com> wrote:

> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)

So you want all three CUA editing keys, C-x, C-c, C-v, to be Emacs
prefix keys, so as to annoy CUA users even more?

Re: Gitlab Migration

[tomas]

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

On Tue, Sep 07, 2021 at 02:26:06PM +0700, Yuri Khan wrote:
> On Tue, 7 Sept 2021 at 11:57, Arthur Miller <arthur.miller@live.com> wrote:
> 
> > Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
> 
> So you want all three CUA editing keys, C-x, C-c, C-v, to be Emacs
> prefix keys, so as to annoy CUA users even more?

CUA (or Microsoftized-copied-from-Apple-CUA: CUA is SHIFT-DEL, CTRL-INS
and SHIFT-INS, remember [1]?) people can just use CUA mode.

Cheers

[1] This only to illustrate how ephemeral those things are: CUA came and
   went, Emacs offered a mode and folks still complain ;-)

 - t

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

Re: Gitlab Migration

[Arthur Miller]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Tue, 7 Sept 2021 at 11:57, Arthur Miller <arthur.miller@live.com> wrote:
>
>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>
> So you want all three CUA editing keys, C-x, C-c, C-v, to be Emacs
> prefix keys, so as to annoy CUA users even more?

:-)

That had nothing to do with CUA. If they can manage two, then they can manager
three as well! :-)

No I actually suggested to swtich C-x and M-x to C-space and M-space, IN AN
ALTERNATIVE setup :), to please CUA users and leave them C-x and M-x prefixes to
use to their contents. But discussion here is getting a soup of rests, people
are picking appart and puttin together statements from different contexts so I
don't think I will care any more :).

Re: Gitlab Migration

[Dmitry Gutov]

On 07.09.2021 07:56, Arthur Miller wrote:
> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
> 
> V is next to c, so all prefixes follow next to each other x,c and v.

I think the current subthread is about adding 'redo' to the default 
bindings set. That would mean not touching the existing bindings, much 
less the important ones.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07.09.2021 07:56, Arthur Miller wrote:
>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
>> V is next to c, so all prefixes follow next to each other x,c and v.
>
> I think the current subthread is about adding 'redo' to the default bindings
> set. That would mean not touching the existing bindings, much less the important
> ones.

Are there any kyes left to add anything new? Adding new prefix to defaults opens
for entire new setup. Maybe some hard to hit key combos could be also rebound to
something easier on new prefix. Yes scroll would have to be rebound, but is it
whole world. You give something to win much more. 

Re: Gitlab Migration

[Dmitry Gutov]

On 07.09.2021 15:49, Arthur Miller wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> On 07.09.2021 07:56, Arthur Miller wrote:
>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
>>> V is next to c, so all prefixes follow next to each other x,c and v.
>> I think the current subthread is about adding 'redo' to the default bindings
>> set. That would mean not touching the existing bindings, much less the important
>> ones.
> Are there any kyes left to add anything new? Adding new prefix to defaults opens
> for entire new setup. Maybe some hard to hit key combos could be also rebound to
> something easier on new prefix. Yes scroll would have to be rebound, but is it
> whole world. You give something to win much more.

I would be totally fine with 'undo-redo' being bound to 'C-?', 'M-_' and 
possibly 'C-x U'. At least as the first step.

If we try to increase the scope of the changes, the odds of anything 
happening at all will get much slimmer.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07.09.2021 15:49, Arthur Miller wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> On 07.09.2021 07:56, Arthur Miller wrote:
>>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
>>>> V is next to c, so all prefixes follow next to each other x,c and v.
>>> I think the current subthread is about adding 'redo' to the default bindings
>>> set. That would mean not touching the existing bindings, much less the important
>>> ones.
>> Are there any kyes left to add anything new? Adding new prefix to defaults opens
>> for entire new setup. Maybe some hard to hit key combos could be also rebound to
>> something easier on new prefix. Yes scroll would have to be rebound, but is it
>> whole world. You give something to win much more.
>
> I would be totally fine with 'undo-redo' being bound to 'C-?', 'M-_' and
> possibly 'C-x U'. At least as the first step.
>
> If we try to increase the scope of the changes, the odds of anything happening
> at all will get much slimmer.

true, for the scope of changes

By the way, I am using M - _ as undo since years back and works fine for me. I
always thought it was the default :). 

Re: Gitlab Migration

[Richard Stallman]

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

  > Others replied later that users generally expect 'redo' to require one 
  > more modifier than 'undo'. In graphical Emacs, it can work out to having 
  > 'C-/' call 'undo', then one can additionally hold down the Shift key to 
  > the right of '/', calling 'redo' with the resulting 'C-?'.

If users are happy with that, I won't argue against it.  It doesn't have
any other problem.

We still have the problem of ttys.  We can't use C-/ or C-? on a tty
because each of them is the same character as DEL.  So we use C-_ instead
for undo.

Because there is no difference on a tty between C-_ and C--.
there is no way to disguinuish between Sh-C-- and C--.

However, C-M-- could be used for redo on ttys.

Does that make everyone happy?  If so, maybe we're ready to
introduce that binding.

Initially we should continue the current behavior of undo
to avoid an incompatible change, and have an option to enablke
the undo-redo behavior.  Once Emacs 28 is out, we could find out
what the users think and whether we old fogeys can adjust to undo-redo.
Then we could decide whether to make that the default.



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

Re: Gitlab Migration

[Dmitry Gutov]

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

On 09.09.2021 06:07, 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. ]]]
> 
>    > Others replied later that users generally expect 'redo' to require one
>    > more modifier than 'undo'. In graphical Emacs, it can work out to having
>    > 'C-/' call 'undo', then one can additionally hold down the Shift key to
>    > the right of '/', calling 'redo' with the resulting 'C-?'.
> 
> If users are happy with that, I won't argue against it.  It doesn't have
> any other problem.
> 
> We still have the problem of ttys.  We can't use C-/ or C-? on a tty
> because each of them is the same character as DEL.  So we use C-_ instead
> for undo.
> 
> Because there is no difference on a tty between C-_ and C--.
> there is no way to disguinuish between Sh-C-- and C--.

I previously suggested M-_ (working fine on my tty), but it does make 
the transition more awkward.

> However, C-M-- could be used for redo on ttys.
> 
> Does that make everyone happy?  If so, maybe we're ready to
> introduce that binding.

That's pretty elegant. On tty, the user would press C-- to undo and 
C-M-- to redo. One-modifier difference.

Though in my testing I had to bind C-M-_ instead. That's what my tty 
Emacs translated the combination to. And that also resolved the conflict 
with the existing 'C-M--' binding for 'negative-argument'.

> Initially we should continue the current behavior of undo
> to avoid an incompatible change, and have an option to enablke
> the undo-redo behavior.  Once Emacs 28 is out, we could find out
> what the users think and whether we old fogeys can adjust to undo-redo.
> Then we could decide whether to make that the default.

Sounds good.

I wonder if we should add some mechanism to detect that the user had 
called undo-redo in the current session, and then one of his/her undo-s 
is going to perform a "redoing" undo (and suggest to disable the 
behavior, by changing some user option that will turn their 'undo' into 
'undo-only').

Or maybe the attached patch is enough: long-time users will use 'undo' 
like they always did, and the undo-redo users aren't generally going to 
notice that 'undo' sometimes goes too far.

We should also modify cua-mode to use undo-redo, but that can go in after.

[-- Attachment #2: undo-redo-bindings.diff --]
[-- Type: text/x-patch, Size: 1188 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index 8f20db7a76..4e12d431a1 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -865,7 +865,13 @@ for CJK text mixed with Latin text.
 +++
 ** New command 'undo-redo'.
 It undoes previous undo commands, but doesn't record itself as an
-undoable command.
+undoable command. It is bound to 'C-?' and 'C-M-_', the first binding
+works well in graphical mode, and the second one is easy to hit on tty.
+
+For full conventional undo/redo behavior, you can also bind undo-only:
+
+    (define-key global-map [?\C-/] 'undo-only)
+    (define-key global-map "\C-_" 'undo-only)
 
 +++
 ** New commands 'copy-matching-lines' and 'kill-matching-lines'.
diff --git a/lisp/bindings.el b/lisp/bindings.el
index b8bf0c1a6f..97a7b01d43 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -993,6 +993,9 @@ undo-repeat-map
   "Keymap to repeat undo key sequences `C-x u u'.  Used in `repeat-mode'.")
 (put 'undo 'repeat-map 'undo-repeat-map)
 
+(define-key global-map (kbd "C-?") 'undo-redo)
+(define-key global-map [?\C-\M-_] 'undo-redo)
+
 (define-key esc-map "!" 'shell-command)
 (define-key esc-map "|" 'shell-command-on-region)
 (define-key esc-map "&" 'async-shell-command)

Re: Gitlab Migration

[Richard Stallman]

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

  > C-M-- to redo. One-modifier difference.

  > Though in my testing I had to bind C-M-_ instead.

That's right.  You can type C-M--, but it really turns into C-M-_.
Same for C--; it really turns into C-_.

  > I wonder if we should add some mechanism to detect that the user had 
  > called undo-redo in the current session, and then one of his/her undo-s 
  > is going to perform a "redoing" undo 

You're trying to solve a problem, but I'm not sure precisely what.  I
think we've made different assumptions and thus are miscommunicating.

My idea was to have two options, undo-only and undo-redo, with a way
for the user to select one.  Initially the default would continue to
be undo-only.  We would ask users try undo-redo; if they generally
like it, we could change the default later to undo-redo.

It looks like you're presuming something different (though I am not
sure what it is) and proposing a DWIM feature for it, but I can't tell.
Would you please spell out both what behavior you're presuming, and
what behavior you propose instead?


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

Re: Gitlab Migration

[Dmitry Gutov]

On 12.09.2021 04:47, 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. ]]]
> 
>    > C-M-- to redo. One-modifier difference.
> 
>    > Though in my testing I had to bind C-M-_ instead.
> 
> That's right.  You can type C-M--, but it really turns into C-M-_.
> Same for C--; it really turns into C-_.

Yep.

>    > I wonder if we should add some mechanism to detect that the user had
>    > called undo-redo in the current session, and then one of his/her undo-s
>    > is going to perform a "redoing" undo
> 
> You're trying to solve a problem, but I'm not sure precisely what.  I
> think we've made different assumptions and thus are miscommunicating.

The plan, as I understood it, was to introduce bindings for the new 
command: undo-redo. But to keep the old binding for 'undo'. Which the 
previous sent patch does.

That can create a problem for users new to Emacs (but with experience 
with some other editors) that, since 'undo' is still not the kind of 
'undo' they are used to, so invoking, for example, 'undo undo right left 
undo', might have a certain unexpected effect. So we could use a 
mechanism to correct it automatically, or suggest to the user how to 
correct it, without them having to read the docs.

That said, the problem of unfamiliar undo isn't new, and certain 
conditions would now need to be met for the user to encounter it (as 
opposed to all previous releases of Emacs, where the lack of 'redo' 
command made the said problem much bigger).

> My idea was to have two options, undo-only and undo-redo, with a way
> for the user to select one.  Initially the default would continue to
> be undo-only.  We would ask users try undo-redo; if they generally
> like it, we could change the default later to undo-redo.

The phrasing of this proposal reads a bit off since the command 
'undo-only' exists, and it does the opposite of what you imagined 
'undo-only' would mean: it it a version of 'undo' which won't redo any 
of the previous 'undo' actions. So it's basically meant to be used 
together with 'undo-redo'.

To restate your proposal how I understood it: we will add a binding for 
'undo-redo', and we will have a user option which will change how 'undo' 
works: either it works as it always did (the default), or it will not 
undo redos. The latter is meant to be used together with 'undo-redo'.

Such variable already exists: undo-no-redo. We can simply turn it into a 
defcustom and document more prominently.

> It looks like you're presuming something different (though I am not
> sure what it is) and proposing a DWIM feature for it, but I can't tell.
> Would you please spell out both what behavior you're presuming, and
> what behavior you propose instead?
I was thinking we would detect that the user had called undo-redo in the 
current session. If they had, and if one of their 'undo' invocations is 
about to "undo a redo", we would suggest to the user, just once, that 
they customize 'undo-no-redo' to t, to prevent this kind of thing from 
happening.

That's the best I could come up with; other suggestions are welcome, of 
course. Or, again, we can choose not to try to solve this now.

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[João Távora]

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

Re: Gitlab Migration

[Clément Pit-Claudel]

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.

Re: Gitlab Migration

[João Távora]

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

Re: Gitlab Migration

[André A. Gomes]

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"

Re: Gitlab Migration

[Yuchen Pei]

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


André A. Gomes <andremegafone@gmail.com> writes:

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

1+

I also want to add some personal thoughts about "old" vs. "young / 
new" in this respect.

I've only used emacs for about one year (had been using vim for 
like 10 years before that), so all the "old" emacs way of doing 
things (both usage and development) have been in fact very new and 
shiny to me, but as it turns out overall I very much prefer these 
"old" ways than the new ways that are older for me :)

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[João Távora]

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

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[John Yates]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[John Yates]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Stefan Kangas]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Philip Kaludercic]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[João Távora]

[-- 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 --]

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

> 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>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:14:20 +0300
> 
> 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.

I'm not sure this is a silly idea: I see on Reddit people saying
they'd like switch from some distro to vanilla Emacs.  When they do
so, they could appreciate starting from something that's close to what
they are familiar with.

In any case, only offering such profiles could tell whether they are
useful or not.

> Spacemacs and Doom don't differ that much between themselves either, not 
> in basic behaviors.

Then maybe we need just one profile, not 2.

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:33, Eli Zaretskii wrote:
>> 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.
> I'm not sure this is a silly idea: I see on Reddit people saying
> they'd like switch from some distro to vanilla Emacs.  When they do
> so, they could appreciate starting from something that's close to what
> they are familiar with.

"Migration to vanilla" usually means hand-crafting the config from 
scratch, knowing what they want, and what they do not, from e.g. Doom 
Emacs. And they usually continue using Evil as well, as well as many 
other third-party packages.

So a vanilla profile is not so important for them as it is for new 
users. But we could add some variation, of course, if someone wants to 
maintain it.

> In any case, only offering such profiles could tell whether they are
> useful or not.

Fair point.

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 13:34 Eli Zaretskii <eliz@gnu.org> wrote:

> > 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>
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Fri, 3 Sep 2021 15:14:20 +0300
> >
> > 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.
> > Spacemacs and Doom don't differ that much between themselves either, not
> > in basic behaviors.
>
> Then maybe we need just one profile, not 2.
>

Fine with me. I've never really used either of those, just know that they
are demonstrably popular sets of settings (unlike many others which are
fallaciously presented here as self-evidently popular). But if those two
are similar enough in the set of options that we are willing or capable to
make configurable via profiles, then one single profile for them it should
be.

The profile's name (or description) should however reflect the proximity to
these popular distributions. I believe this familiarity hint goes some way
into convincing users.

João

>

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

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 13:14 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On
> > migrating from those distributions. Not sure about vi kebinds though,
> ugh...
>
> That's a little silly:


I merely meant to take those popular selection of preferences as a starting
point, and not necessarily your pet peeves. Seems perfectly reasonable to
me.

Also, I don't have to keep up with your constant and combatant rudeness.
Goodbye.

João

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 13:30 Eli Zaretskii <eliz@gnu.org> wrote:

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

Bear in mind that other packages are affected where bugs are not reported
via report-emacs-bugs. But I agree that there is still a way -- there
always is -- to determine the configuration that a user is using. My point
is that it should be very easy to do that, i.e to report and control that
big set of preferences, almost as easy as it is when one uses Emacs -Q,
which is, for me, also a way to control to a very large number of
preferences.

Even with the convenience of Emacs -Q, I already have a lot of trouble
explaining and attaining reproducibility from some users. So, as a package
developer, I'd appreciate Emacs -Qprofile-name (or equivalent). This is
essential to interact with users who will, over time, become completely
helpless when presented with a good-old-days Emacs  -Q (with non-vi
bindings, of all things...)

João

>

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Dmitry Gutov]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Christian Vanderwall]

On Fri, Sep 03 2021, 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.
>
> 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.

UX themes are a neat idea, but does it makes sense to include them in Emacs when external configs like Emacs Prelude exist? I think most new Emacs users these days get started by following a blog post or online tutorial. Those resources usually include an opinionated set of defaults that they suggest the user change right away.

Instead of selecting a profile/theme, what if new users could walk through an interactive configuration tutorial? The config tutorial would walk them through the commonly changed defaults, letting them decide which to change, and teaching them to persist changes in their init.el or via Customize in the process.

-- 
Christian Vanderwall

Re: Gitlab Migration

[Stefan Kangas]

Christian Vanderwall <christian@cvdub.net> writes:

> UX themes are a neat idea, but does it makes sense to include them in Emacs when external configs like Emacs Prelude exist?

I think so, yes.  We are discussing how to improve the OOTB experience.

> Instead of selecting a profile/theme, what if new users could walk through an interactive configuration tutorial? The config tutorial would walk them through the commonly changed defaults, letting them decide which to change, and teaching them to persist changes in their init.el or via Customize in the process.

There is currently a separate discussion taking place on this list
about this.  I suggest you take a look at it.

Re: Gitlab Migration

[Richard Stallman]

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

  > We're literally under no "obligation" to anything. But is it a
  > good outcome?

The reason we are reluctant to change default behaviors is that
we believe that upward compatibiluty for such things is usually
a good outcome.


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

Re: Gitlab Migration

[John Yates]

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.

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[João Távora]

[-- 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 --]

Re: Gitlab Migration

[Arthur Miller]

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? 

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Augusto Stoffel]

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.

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[john muhl]

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

Re: Gitlab Migration

[Daniel Fleischer]

[-- 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*

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Yuchen Pei]

[-- 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 --]

Re: Gitlab Migration

[Richard Stallman]

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

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

Re: Gitlab Migration

[Po Lu]

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.

Re: Gitlab Migration

[Daniel Martín]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Daniel Martín]

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.

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Daniel Martín]

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.

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[Arthur Miller]

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

Re: Gitlab Migration

[Stefan Monnier]

> 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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Alan Third]

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

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Basil L. Contovounesios]

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

Re: Gitlab Migration

[Alan Third]

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

Re: Gitlab Migration

[Richard Stallman]

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

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)

Re: Gitlab Migration

[Arthur Miller]

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"?

Re: Gitlab Migration

[Eli Zaretskii]

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

Re: Gitlab Migration

[Yuchen Pei]

[-- 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 --]

Re: Gitlab Migration

[Eli Zaretskii]

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