bug#34889: [RFE] Migration to gitlab

bug#34889: [RFE] Migration to gitlab

[Konstantin Kharlamov]

I want to start by answering first likely question: the Community 
Edition of gitlab should be fine license-wise, quoting Richard Stallman 
"We have a simple way of looking at these two versions. The free 
version is free software, so it is ethical."¹

Terms: "merge request" in gitlab means "patch series sent for review".

----

It makes me sad, seeing Emacs addons popping up, for a functional that 
better could've been implemented in core. It's a lot of contributors 
out there; at the same time, I see very little patches on emacs-devel 
list.

A lot of open-source projects already migrated to gitlab: all 
FreeDesktop projects, all Gnome projects; and KDE are likely to migrate 
soon too². Gnome reports: "After switching to GitLab, I noticed almost 
immediately an increase in contributions from people I hadn’t met 
before. I think GitLab really lowered the threshold for people getting 
started"³.

So, at the very least, migrating to gitlab should make contributions 
easier for bigger part of the open-source world, peoples who used to 
github and gitlab. (btw, here's a rarely mentioned point, why in 
particular mailing-list workflow is hard for newcomers: almost every 
mail client out there breaks formatting by default; and configuring 
that out isn't always easy).

Other points include:
	1. I know some people like to operate with mails rather than 
web-interface (which is what usual gitlab workflow based on). For them 
gitlab can be configured to be managed with mails. I don't know how far 
it stretches, but at the very least creating/replying to issues/merge 
requests can be enabled.⁴
	2. Gitlab makes addressing review comments easier. With mailing lists 
workflow you either need to α) send a v2 of the patch; which is a 
little frustrating: you need to find message-id to feed it to 
git-send-email, and then you need to make sure its title lines up with 
the rest of the series. Or β) resend whole patch-series; which can be 
just redundant when all you did was a one-line change, and clutters the 
mailing list. Also, upon sending v3, v4, etc. you need to save 
somewhere changes since v1. You can put it in actual commits, but for 
git-history this information is unnecessary. With gitlab workflow, on 
the other hand, you just force-push changes to the branch that has 
merge-request opened. A single command, that it.
	3. CI. I've recently seen someone on emacs-devel⁵ asking a 
contributor to run their syntax-checking script on a regular basis. 
That's becase you can't run any check on a code hanging out there on a 
mailing list in pure air. Gitlab supports CI, i.e. one can set it up to 
run unit-tests for every merge-request created, so these errors get 
caught before getting to the tree; and possibly even before getting to 
eyes of reveiwers.
	4. Impossible to lose "merge request". I've seen in Emacs docs an 
advice to send patch series to a bugtracker, because on emacs-devel 
they can easily be forgotten. That can't happen so easily with gitlab, 
where you have a tab with open merge requests.
	5. Discussion on patch series is easier to read. On mailing lists can 
quickly appear a dozen of no longer relevant review mails, that refer 
to something that was addressed. In Gitlab the addressed comments can 
be marked as such, and get collapsed.
	6. More tightly integrated bugtracker. When a commit refers to an 
issue, it can be seen from inside the issue. This is useful e.g. when 
someone fixed a problem, but for some reason couldn't address review 
comments, leaving the code behind. Then later peoples who stumble upon 
the same issue can just improve the code instead of doing research and 
writing it on their own.
	7. Unclear how to download a patch-series from mailing list. Usually 
mailing-list driven projects add some system that tracks patches, and 
allows to download series. E.g. that's how Mesa worked. But Emacs don't 
seem to have one. With gitlab though you can simply fetch someone's 
branch.

1: 
https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
2: 
http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
4: https://docs.gitlab.com/ee/administration/incoming_email.html
5: http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov 
<hi-angel@yandex.ru> написал:
> I want to start by answering first likely question: the Community 
> Edition of gitlab should be fine license-wise, quoting Richard 
> Stallman "We have a simple way of looking at these two versions. The 
> free version is free software, so it is ethical."¹
> 
> Terms: "merge request" in gitlab means "patch series sent for review".
> 
> ----
> 
> It makes me sad, seeing Emacs addons popping up, for a functional 
> that better could've been implemented in core. It's a lot of 
> contributors out there; at the same time, I see very little patches 
> on emacs-devel list.
> 
> A lot of open-source projects already migrated to gitlab: all 
> FreeDesktop projects, all Gnome projects; and KDE are likely to 
> migrate soon too². Gnome reports: "After switching to GitLab, I 
> noticed almost immediately an increase in contributions from people I 
> hadn’t met before. I think GitLab really lowered the threshold for 
> people getting started"³.
> 
> So, at the very least, migrating to gitlab should make contributions 
> easier for bigger part of the open-source world, peoples who used to 
> github and gitlab. (btw, here's a rarely mentioned point, why in 
> particular mailing-list workflow is hard for newcomers: almost every 
> mail client out there breaks formatting by default; and configuring 
> that out isn't always easy).
> 
> Other points include:
> 	1. I know some people like to operate with mails rather than 
> web-interface (which is what usual gitlab workflow based on). For 
> them gitlab can be configured to be managed with mails. I don't know 
> how far it stretches, but at the very least creating/replying to 
> issues/merge requests can be enabled.⁴
> 	2. Gitlab makes addressing review comments easier. With mailing 
> lists workflow you either need to α) send a v2 of the patch; which 
> is a little frustrating: you need to find message-id to feed it to 
> git-send-email, and then you need to make sure its title lines up 
> with the rest of the series. Or β) resend whole patch-series; which 
> can be just redundant when all you did was a one-line change, and 
> clutters the mailing list. Also, upon sending v3, v4, etc. you need 
> to save somewhere changes since v1. You can put it in actual commits, 
> but for git-history this information is unnecessary. With gitlab 
> workflow, on the other hand, you just force-push changes to the 
> branch that has merge-request opened. A single command, that it.
> 	3. CI. I've recently seen someone on emacs-devel⁵ asking a 
> contributor to run their syntax-checking script on a regular basis. 
> That's becase you can't run any check on a code hanging out there on 
> a mailing list in pure air. Gitlab supports CI, i.e. one can set it 
> up to run unit-tests for every merge-request created, so these errors 
> get caught before getting to the tree; and possibly even before 
> getting to eyes of reveiwers.
> 	4. Impossible to lose "merge request". I've seen in Emacs docs an 
> advice to send patch series to a bugtracker, because on emacs-devel 
> they can easily be forgotten. That can't happen so easily with 
> gitlab, where you have a tab with open merge requests.
> 	5. Discussion on patch series is easier to read. On mailing lists 
> can quickly appear a dozen of no longer relevant review mails, that 
> refer to something that was addressed. In Gitlab the addressed 
> comments can be marked as such, and get collapsed.
> 	6. More tightly integrated bugtracker. When a commit refers to an 
> issue, it can be seen from inside the issue. This is useful e.g. when 
> someone fixed a problem, but for some reason couldn't address review 
> comments, leaving the code behind. Then later peoples who stumble 
> upon the same issue can just improve the code instead of doing 
> research and writing it on their own.
> 	7. Unclear how to download a patch-series from mailing list. Usually 
> mailing-list driven projects add some system that tracks patches, and 
> allows to download series. E.g. that's how Mesa worked. But Emacs 
> don't seem to have one. With gitlab though you can simply fetch 
> someone's branch.
> 
> 1: 
> https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
> 2: 
> http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
> 3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
> 4: https://docs.gitlab.com/ee/administration/incoming_email.html
> 5: http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html

Btw, one more point I just got: no more discrepancy between what 
mailing list subscribers see, and what web-interface renders. E.g. the 
nicely formatted list of points above from the outside worls looks like 
a large single line: 
http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html

bug#34889: [RFE] Migration to gitlab

[Konstantin Kharlamov]

Oops. Please, reply to this mail, I haven't thought that mails to 
bugs-gnu gonna create new reports. Fixed here.

В Вс, мар 17, 2019 at 6:01 ДП (AM), Konstantin Kharlamov 
<hi-angel@yandex.ru> написал:
> 
> 
> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov 
> <hi-angel@yandex.ru> написал:
>> I want to start by answering first likely question: the Community 
>> \x7fEdition of gitlab should be fine license-wise, quoting Richard 
>> \x7fStallman "We have a simple way of looking at these two versions. 
>> The \x7ffree version is free software, so it is ethical."¹
>> 
>> Terms: "merge request" in gitlab means "patch series sent for 
>> review".
>> 
>> ----
>> 
>> It makes me sad, seeing Emacs addons popping up, for a functional 
>> \x7fthat better could've been implemented in core. It's a lot of 
>> \x7fcontributors out there; at the same time, I see very little patches 
>> \x7fon emacs-devel list.
>> 
>> A lot of open-source projects already migrated to gitlab: all 
>> \x7fFreeDesktop projects, all Gnome projects; and KDE are likely to 
>> \x7fmigrate soon too². Gnome reports: "After switching to GitLab, I 
>> \x7fnoticed almost immediately an increase in contributions from people 
>> I \x7fhadn’t met before. I think GitLab really lowered the threshold 
>> for \x7fpeople getting started"³.
>> 
>> So, at the very least, migrating to gitlab should make contributions 
>> \x7feasier for bigger part of the open-source world, peoples who used 
>> to \x7fgithub and gitlab. (btw, here's a rarely mentioned point, why in 
>> \x7fparticular mailing-list workflow is hard for newcomers: almost 
>> every \x7fmail client out there breaks formatting by default; and 
>> configuring \x7fthat out isn't always easy).
>> 
>> Other points include:
>> 	1. I know some people like to operate with mails rather than 
>> \x7fweb-interface (which is what usual gitlab workflow based on). For 
>> \x7fthem gitlab can be configured to be managed with mails. I don't 
>> know \x7fhow far it stretches, but at the very least creating/replying 
>> to \x7fissues/merge requests can be enabled.⁴
>> 	2. Gitlab makes addressing review comments easier. With mailing 
>> \x7flists workflow you either need to α) send a v2 of the patch; which 
>> \x7fis a little frustrating: you need to find message-id to feed it to 
>> \x7fgit-send-email, and then you need to make sure its title lines up 
>> \x7fwith the rest of the series. Or β) resend whole patch-series; 
>> which \x7fcan be just redundant when all you did was a one-line change, 
>> and \x7fclutters the mailing list. Also, upon sending v3, v4, etc. you 
>> need \x7fto save somewhere changes since v1. You can put it in actual 
>> commits, \x7fbut for git-history this information is unnecessary. With 
>> gitlab \x7fworkflow, on the other hand, you just force-push changes to 
>> the \x7fbranch that has merge-request opened. A single command, that it.
>> 	3. CI. I've recently seen someone on emacs-devel⁵ asking a 
>> \x7fcontributor to run their syntax-checking script on a regular basis. 
>> \x7fThat's becase you can't run any check on a code hanging out there 
>> on \x7fa mailing list in pure air. Gitlab supports CI, i.e. one can set 
>> it \x7fup to run unit-tests for every merge-request created, so these 
>> errors \x7fget caught before getting to the tree; and possibly even 
>> before \x7fgetting to eyes of reveiwers.
>> 	4. Impossible to lose "merge request". I've seen in Emacs docs an 
>> \x7fadvice to send patch series to a bugtracker, because on emacs-devel 
>> \x7fthey can easily be forgotten. That can't happen so easily with 
>> \x7fgitlab, where you have a tab with open merge requests.
>> 	5. Discussion on patch series is easier to read. On mailing lists 
>> \x7fcan quickly appear a dozen of no longer relevant review mails, that 
>> \x7frefer to something that was addressed. In Gitlab the addressed 
>> \x7fcomments can be marked as such, and get collapsed.
>> 	6. More tightly integrated bugtracker. When a commit refers to an 
>> \x7fissue, it can be seen from inside the issue. This is useful e.g. 
>> when \x7fsomeone fixed a problem, but for some reason couldn't address 
>> review \x7fcomments, leaving the code behind. Then later peoples who 
>> stumble \x7fupon the same issue can just improve the code instead of 
>> doing \x7fresearch and writing it on their own.
>> 	7. Unclear how to download a patch-series from mailing list. 
>> Usually \x7fmailing-list driven projects add some system that tracks 
>> patches, and \x7fallows to download series. E.g. that's how Mesa 
>> worked. But Emacs \x7fdon't seem to have one. With gitlab though you 
>> can simply fetch \x7fsomeone's branch.
>> 
>> 1: 
>> \x7fLINKIFYGEGDJECbEADBFHecaGEGGBDcecHaECcDAAdIGfff
>> 2: 
>> \x7fLINKIFYfcGDJddJJDEJcbfEHJICGcIEaIaeFfeHIdJEdedD
>> 3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
>> 4: https://docs.gitlab.com/ee/administration/incoming_email.html
>> 5: 
>> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html
> 
> Btw, one more point I just got: no more discrepancy between what 
> mailing list subscribers see, and what web-interface renders. E.g. 
> the nicely formatted list of points above from the outside worls 
> looks like a large single line: 
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html
> 
> 
> 

Re: [RFE] Migration to gitlab

[Tim Cross]

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

Just for clarification, is your suggestion that savannah.gnu.org be changed
to use GitLab instead of the current web interface or that GNU Emacs is
moved from savannah to a new home based on GitLab?

One thing I think you have possibly overlooked or glossed over is the
copyright requirements for contributions to GNU Emacs. I suspect this is
one of the reasons Emacs is not developed in a similar fashion to other
projects which are based on the use of pull requests etc.

GitLab is a good package. We use it to manage our projects and find it very
good. The CI and DevOps support is very useful for the types of projects we
do. For GNU Emacs, the CI stuff could be useful as a way to automate
running of test suites etc, but I can't see any benefit from the DevOps
perspective. The issue tracker is OK, but not sure it would meet the
demands associated with GNU Emacs. There are already existing Emacs wiki
sites, so adding another wiki is possibly of little benefit. Many of the
other GitLab features are likewise of marginal benefit given the specific
nature of this project.

It would be a big job to migrate savannah.gnu.org to GitLab and you have
the issue that despite the licensing, it isn't a GNU project, where I
suspect all the interface etc on savannah is. I guess it would be for those
who maintain that system to evaluate and make the call. I'm not convinced
the effort would provide the benefits suggested. Reality is, those keen
enough to complete the copyright assignment documents and commit to Emacs
development are unlikely to use any web interface - instead just using git
on the command line. The GitLab model works well where you have
contributors with more 'casual' connection to the project.

On Sun, 17 Mar 2019 at 14:57, Konstantin Kharlamov <hi-angel@yandex.ru>
wrote:

> Oops. Please, reply to this mail, I haven't thought that mails to
> bugs-gnu gonna create new reports. Fixed here.
>
> В Вс, мар 17, 2019 at 6:01 ДП (AM), Konstantin Kharlamov
> <hi-angel@yandex.ru> написал:
> >
> >
> > В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> > <hi-angel@yandex.ru> написал:
> >> I want to start by answering first likely question: the Community
> >>  Edition of gitlab should be fine license-wise, quoting Richard
> >>  Stallman "We have a simple way of looking at these two versions.
> >> The  free version is free software, so it is ethical."¹
> >>
> >> Terms: "merge request" in gitlab means "patch series sent for
> >> review".
> >>
> >> ----
> >>
> >> It makes me sad, seeing Emacs addons popping up, for a functional
> >>  that better could've been implemented in core. It's a lot of
> >>  contributors out there; at the same time, I see very little patches
> >>  on emacs-devel list.
> >>
> >> A lot of open-source projects already migrated to gitlab: all
> >>  FreeDesktop projects, all Gnome projects; and KDE are likely to
> >>  migrate soon too². Gnome reports: "After switching to GitLab, I
> >>  noticed almost immediately an increase in contributions from people
> >> I  hadn’t met before. I think GitLab really lowered the threshold
> >> for  people getting started"³.
> >>
> >> So, at the very least, migrating to gitlab should make contributions
> >>  easier for bigger part of the open-source world, peoples who used
> >> to  github and gitlab. (btw, here's a rarely mentioned point, why in
> >>  particular mailing-list workflow is hard for newcomers: almost
> >> every  mail client out there breaks formatting by default; and
> >> configuring  that out isn't always easy).
> >>
> >> Other points include:
> >>      1. I know some people like to operate with mails rather than
> >>  web-interface (which is what usual gitlab workflow based on). For
> >>  them gitlab can be configured to be managed with mails. I don't
> >> know  how far it stretches, but at the very least creating/replying
> >> to  issues/merge requests can be enabled.⁴
> >>      2. Gitlab makes addressing review comments easier. With mailing
> >>  lists workflow you either need to α) send a v2 of the patch; which
> >>  is a little frustrating: you need to find message-id to feed it to
> >>  git-send-email, and then you need to make sure its title lines up
> >>  with the rest of the series. Or β) resend whole patch-series;
> >> which  can be just redundant when all you did was a one-line change,
> >> and  clutters the mailing list. Also, upon sending v3, v4, etc. you
> >> need  to save somewhere changes since v1. You can put it in actual
> >> commits,  but for git-history this information is unnecessary. With
> >> gitlab  workflow, on the other hand, you just force-push changes to
> >> the  branch that has merge-request opened. A single command, that it.
> >>      3. CI. I've recently seen someone on emacs-devel⁵ asking a
> >>  contributor to run their syntax-checking script on a regular basis.
> >>  That's becase you can't run any check on a code hanging out there
> >> on  a mailing list in pure air. Gitlab supports CI, i.e. one can set
> >> it  up to run unit-tests for every merge-request created, so these
> >> errors  get caught before getting to the tree; and possibly even
> >> before  getting to eyes of reveiwers.
> >>      4. Impossible to lose "merge request". I've seen in Emacs docs an
> >>  advice to send patch series to a bugtracker, because on emacs-devel
> >>  they can easily be forgotten. That can't happen so easily with
> >>  gitlab, where you have a tab with open merge requests.
> >>      5. Discussion on patch series is easier to read. On mailing lists
> >>  can quickly appear a dozen of no longer relevant review mails, that
> >>  refer to something that was addressed. In Gitlab the addressed
> >>  comments can be marked as such, and get collapsed.
> >>      6. More tightly integrated bugtracker. When a commit refers to an
> >>  issue, it can be seen from inside the issue. This is useful e.g.
> >> when  someone fixed a problem, but for some reason couldn't address
> >> review  comments, leaving the code behind. Then later peoples who
> >> stumble  upon the same issue can just improve the code instead of
> >> doing  research and writing it on their own.
> >>      7. Unclear how to download a patch-series from mailing list.
> >> Usually  mailing-list driven projects add some system that tracks
> >> patches, and  allows to download series. E.g. that's how Mesa
> >> worked. But Emacs  don't seem to have one. With gitlab though you
> >> can simply fetch  someone's branch.
> >>
> >> 1:
> >>
> https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
> >> 2:
> >>
> http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
> >> 3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
> >> 4: https://docs.gitlab.com/ee/administration/incoming_email.html
> >> 5:
> >> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html
> >
> > Btw, one more point I just got: no more discrepancy between what
> > mailing list subscribers see, and what web-interface renders. E.g.
> > the nicely formatted list of points above from the outside worls
> > looks like a large single line:
> > http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html
> >
> >
> >
>
>
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: [RFE] Migration to gitlab

[Michael Albinus]

Tim Cross <theophilusx@gmail.com> writes:

> GitLab is a good package. We use it to manage our projects and find it
> very good. The CI and DevOps support is very useful for the types of
> projects we do. For GNU Emacs, the CI stuff could be useful as a way
> to automate running of test suites etc

That exists aleady. <https://emba.gnu.org/emacs/emacs/pipelines>.

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Вс, мар 17, 2019 at 11:20 ДП (AM), Tim Cross 
<theophilusx@gmail.com> написал:
> 
> Just for clarification, is your suggestion that savannah.gnu.org be 
> changed to use GitLab instead of the current web interface or that 
> GNU Emacs is moved from savannah to a new home based on GitLab?

That GNU Emacs moved to a gitlab.

savannah.gnu.org looks like a news site, I doubt gitlab would be a good 
fit there.

> One thing I think you have possibly overlooked or glossed over is the 
> copyright requirements for contributions to GNU Emacs. I suspect this 
> is one of the reasons Emacs is not developed in a similar fashion to 
> other projects which are based on the use of pull requests etc.

I've just read a bit about that. I might be missing some nuances of the 
process, but right now I don't see how using merge requests vs emails 
could interfere.

> GitLab is a good package. We use it to manage our projects and find 
> it very good. The CI and DevOps support is very useful for the types 
> of projects we do. For GNU Emacs, the CI stuff could be useful as a 
> way to automate running of test suites etc, but I can't see any 
> benefit from the DevOps perspective. The issue tracker is OK, but not 
> sure it would meet the demands associated with GNU Emacs. There are 
> already existing Emacs wiki sites, so adding another wiki is possibly 
> of little benefit. Many of the other GitLab features are likewise of 
> marginal benefit given the specific nature of this project.

There still are points besides the CI that I had in the initial email. 
TL;DR of that is: the threshold for first contributions is very high. I 
have been contributing to email-based projects for a while, and even I 
still feel a little uncomfortable compared to merge/pull requests 
workflow.

If an arbitrary newcomer out there would consider "Hmm, I have used 
Emacs and Visual Studio Code, where do I want to contribute"; they 
easily gonna stop half-way through figuring out how to send a patch, 
and not gonna contribute to Emacs.

I also think out there in ".emacs" configs a lot of workarounds for 
something that could've been changed inside Emacs instead. Because of 
the threshold.

> It would be a big job to migrate savannah.gnu.org to GitLab and you 
> have the issue that despite the licensing, it isn't a GNU project, 
> where I suspect all the interface etc on savannah is. I guess it 
> would be for those who maintain that system to evaluate and make the 
> call. I'm not convinced the effort would provide the benefits 
> suggested. Reality is, those keen enough to complete the copyright 
> assignment documents and commit to Emacs development are unlikely to 
> use any web interface - instead just using git on the command line. 
> The GitLab model works well where you have contributors with more 
> 'casual' connection to the project.

As I noted in initial mail, gitlab can be configured to create merge 
requests from a command line. Also just "sign the copyright assignment" 
vs "sign the copyright assignment, then struggle with the workflow (I'm 
referring to the rest of the points)" are setting very different 
thresholds for contribution.

And, is having "casual contributors" bad? How many new "commited" 
developers have you got in last few years?

Commitment to a project is not something that happens overnight. You 
first have a casual contributor, who sends occasional fixes and patches 
because he likes the project, and wants to share it with others. After 
a lot of time and discussions as he gets more acknowledged with 
internals and peoples around he might start considering "What if I help 
maintaining the project?".

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sun, 17 Mar 2019 14:16:36 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> savannah.gnu.org looks like a news site

Are you sure you are looking at the right page?  You should be looking
here:

  https://savannah.gnu.org/projects/emacs

> > One thing I think you have possibly overlooked or glossed over is the 
> > copyright requirements for contributions to GNU Emacs. I suspect this 
> > is one of the reasons Emacs is not developed in a similar fashion to 
> > other projects which are based on the use of pull requests etc.
> 
> I've just read a bit about that. I might be missing some nuances of the 
> process, but right now I don't see how using merge requests vs emails 
> could interfere.

It doesn't interfere, but it slows down the process for new
contributors, so doing this stuff quickly is no longer an attainable
goal.

> If an arbitrary newcomer out there would consider "Hmm, I have used 
> Emacs and Visual Studio Code, where do I want to contribute"; they 
> easily gonna stop half-way through figuring out how to send a patch, 
> and not gonna contribute to Emacs.

Sending patches via email is only one requirement.  There are other
requirements peculiar to Emacs, which will not go away if we switch to
another patch submitting system.  Some of these requirements, each and
every one of them flagged at some point as an obstacle for newcomers:

  . code submissions should include documentation
  . commit log messages should be formatted in a certain way
  . bug numbers should be referenced in log messages
  . US English conventions in writing comments and documentation
    (spelling, two spaces between sentences, etc.)
  . we require copyright assignments for accepting changesets larger
    than about 15 original source lines
  . we have peculiar rules regarding the branch were certain changes
    should be pushed (affects the branch against which contributors
    should prepare patches)
  . very elaborate coding and documenting conventions (their
    description takes around 900 lines in the ELisp manual)

So as you see, being a contributor to Emacs is not easy and takes some
getting used to.  Plenty of reasons for arbitrary newcomers not to be
bothered, whether or not we use Gitlab.  Contributing to Emacs needs a
lot of motivation regardless.  We shouldn't forget that when we
discuss individual issues.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 17.03.2019 20:05, Eli Zaretskii wrote:
>> savannah.gnu.org looks like a news site
> 
> Are you sure you are looking at the right page?  You should be looking
> here:
> 
>    https://savannah.gnu.org/projects/emacs

I can't help but feel that the mentions of Savannah in this thread are 
disingenuous. After registering there, adding an ssh key and sending the 
membership request for the emacs project, I never went back there, or 
used it for anything else. This is, I suspect, the case for many other 
contributors as well.

So since Savannah's role is very minor, I wouldn't say we need to do 
anything with it. Maybe Emacs' gitlab installation will be the place to 
add the ssh keys, though.

>> I've just read a bit about that. I might be missing some nuances of the
>> process, but right now I don't see how using merge requests vs emails
>> could interfere.
> 
> It doesn't interfere, but it slows down the process for new
> contributors, so doing this stuff quickly is no longer an attainable
> goal.

Wouldn't the said contributors still be able to submit patches over 
email anyway?

On the other hand, the CI could check all the included commits in a PR 
for their authors and the copyright assignments of each. And GitLab 
would show that this particular check failed, which could be more 
accessible for a contributor than reading up on patch submission 
conditions in the documentation.

> Sending patches via email is only one requirement.  There are other
> requirements peculiar to Emacs, which will not go away if we switch to
> another patch submitting system.  Some of these requirements, each and
> every one of them flagged at some point as an obstacle for newcomers:
> 
>    . code submissions should include documentation
>    . commit log messages should be formatted in a certain way
>    . bug numbers should be referenced in log messages
>    . US English conventions in writing comments and documentation
>      (spelling, two spaces between sentences, etc.)
>    . we require copyright assignments for accepting changesets larger
>      than about 15 original source lines
>    . we have peculiar rules regarding the branch were certain changes
>      should be pushed (affects the branch against which contributors
>      should prepare patches)
>    . very elaborate coding and documenting conventions (their
>      description takes around 900 lines in the ELisp manual)

At least some of these checks could be automated on a CI. And the author 
of a random PR would get an overview of its compliance automatically.

So the closer the CI is to Emacs's home page, and to patch submission 
process, the easier it might be for a new contributor to receive 
automatic feedback on their work.

All of this should be prepended with the work "potentially", but still. 
Gitlab has the ability to improve the experience of both contributors 
and the maintainers, if we make use of the tools it offers.

Re: [RFE] Migration to gitlab

[Glenn Morris]

Dmitry Gutov wrote:

> I can't help but feel that the mentions of Savannah in this thread are
> disingenuous. After registering there, adding an ssh key and sending
> the membership request for the emacs project, I never went back there,
> or used it for anything else. This is, I suspect, the case for many
> other contributors as well.

Everyone uses Savannah every time they push or pull a commit to/from
Emacs, or reads the diff list, or looks at cgit. We rely on the Savannah
hackers to maintain a secure, reliable, and robust repository. There are
issues of authentication, managing user accounts, keeping the system
up-to-date, security, scaling, managing the web server, backups, etc, to
deal with. I think they have done a great job for years.

This was true in the Bazaar days, and CVS before. I can't remember a
time when the Emacs developers have ever managed their own repository.
I wouldn't like that responsibility.

(I assume non-self-hosted gitlab is a non-starter as per
https://www.gnu.org/software/repo-criteria-evaluation.html )

I would hope a hypothetical self-hosted gitlab, if acceptable, would be
open to all GNU projects, as Savannah is. Even if not, it's still a big
and ongoing job to be responsible for such a system.

Re: [RFE] Migration to gitlab

[Glenn Morris]

Glenn Morris wrote (on Mon, 18 Mar 2019 at 21:43 -0400):

> (I assume non-self-hosted gitlab is a non-starter as per
> https://www.gnu.org/software/repo-criteria-evaluation.html )

Oh, I see grade C is apparently "acceptable" according to
https://www.gnu.org/software/repo-criteria.html

But not according to
http://lists.gnu.org/r/emacs-devel/2019-03/msg00594.html

Anyway, I mainly wanted to answer the sentiment "what has Savannah
ever done for us".

Re: [RFE] Migration to gitlab

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

  > Oh, I see grade C is apparently "acceptable" according to
  > https://www.gnu.org/software/repo-criteria.html

  > But not according to
  > http://lists.gnu.org/r/emacs-devel/2019-03/msg00594.html

I don't know what is in that URL, but if you're talking about the
message I posted about this recently, please keep in mind that these
are two different questions, acceptable for two different purposes.
They can have two different answers.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Konstantin Kharlamov <hi-angel@yandex.ru>,  theophilusx@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 18 Mar 2019 21:43:20 -0400
> 
> Everyone uses Savannah every time they push or pull a commit to/from
> Emacs, or reads the diff list, or looks at cgit. We rely on the Savannah
> hackers to maintain a secure, reliable, and robust repository. There are
> issues of authentication, managing user accounts, keeping the system
> up-to-date, security, scaling, managing the web server, backups, etc, to
> deal with. I think they have done a great job for years.

100% agreement.

> This was true in the Bazaar days, and CVS before. I can't remember a
> time when the Emacs developers have ever managed their own repository.

I think last time that was true, it was an RCS repository on RMS's
personal machine, and he was applying all the patches locally.  That
all went away when Emacs switched to CVS, in 1993, I think.

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> > Sending patches via email is only one requirement.  There are other
> > requirements peculiar to Emacs, which will not go away if we switch to
> > another patch submitting system.  Some of these requirements, each and
> > every one of them flagged at some point as an obstacle for newcomers:
> >
> >    . code submissions should include documentation
> >    . commit log messages should be formatted in a certain way
> >    . bug numbers should be referenced in log messages
> >    . US English conventions in writing comments and documentation
> >      (spelling, two spaces between sentences, etc.)
> >    . we require copyright assignments for accepting changesets larger
> >      than about 15 original source lines
> >    . we have peculiar rules regarding the branch were certain changes
> >      should be pushed (affects the branch against which contributors
> >      should prepare patches)
> >    . very elaborate coding and documenting conventions (their
> >      description takes around 900 lines in the ELisp manual)
>
> At least some of these checks could be automated on a CI. And the author
> of a random PR would get an overview of its compliance automatically.
>

Also when someone creates a PR (or Issue), there can be template text (with
checkboxes, etc) stating these points, so the author has a direct reminder
to improve the quality of his PR or Issue before he sends it.

And if he does not check all the checboxes and submit anyway, then the
maintainer's job is easier because he already knows the missing parts.

I believe this whole discussion is basically this: the ones who are used to
a gitlab workflow see the obvious benefits, and the ones who only use the
email workflow don't see what's so great about it because they always find
a manual/configuration-heavy way to achieve the same.

I think the manual/configuration-heavy way is not very smooth and makes
_you_ work instead of the tools, when this effort could be better spent
improving Emacs.

Kind regards,
Philippe

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

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Tue, Mar 19, 2019 at 8:28 AM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
> I believe this whole discussion is basically this: the ones who are used to a gitlab workflow see the obvious benefits, and the ones who only use the email workflow don't see what's so great about it because they always find a manual/configuration-heavy way to achieve the same.
>
> I think the manual/configuration-heavy way is not very smooth and makes _you_ work instead of the tools, when this effort could be better spent improving Emacs.

IMO, that point is moot when we are talking about making contributions
to Emacs.  Instead of an RFE to migrate to gitlab, an RFE for a
package that, for example, enhances Emacs bug reporting so that it
becomes a CI tool would be better, no?

> Kind regards,
> Philippe

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> > I believe this whole discussion is basically this: the ones who are used
> to a gitlab workflow see the obvious benefits, and the ones who only use
> the email workflow don't see what's so great about it because they always
> find a manual/configuration-heavy way to achieve the same.
> >
> > I think the manual/configuration-heavy way is not very smooth and makes
> _you_ work instead of the tools, when this effort could be better spent
> improving Emacs.
>
> IMO, that point is moot when we are talking about making contributions
> to Emacs.  Instead of an RFE to migrate to gitlab, an RFE for a
> package that, for example, enhances Emacs bug reporting so that it
> becomes a CI tool would be better, no?


Well, an Emacs custom-made CI tool will never be as complete, time-tested,
maintainted (etc) than a tool that is used by hundred of thousands of
users. Also if any of these gitlab/github/etc users want to contribute to
Emacs, the time to start being "productive" is very low because they are
used to this workflow (and most of them are not used to the mailing list
workflow).

I think the effort required to understand & use the mailing list workflow
is quite significant at the start, then after a while you get used to it...
but in my case I'd switch to the gitlab workflow as soon as it is
available. It's very likely that others here would switch too if it was
available.

Best regards,
Philippe

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

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Tue, Mar 19, 2019 at 1:31 PM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>>
>> > I believe this whole discussion is basically this: the ones who are used to a gitlab workflow see the obvious benefits, and the ones who only use the email workflow don't see what's so great about it because they always find a manual/configuration-heavy way to achieve the same.
>> >
>> > I think the manual/configuration-heavy way is not very smooth and makes _you_ work instead of the tools, when this effort could be better spent improving Emacs.
>>
>> IMO, that point is moot when we are talking about making contributions
>> to Emacs.  Instead of an RFE to migrate to gitlab, an RFE for a
>> package that, for example, enhances Emacs bug reporting so that it
>> becomes a CI tool would be better, no?
>
>
> Well, an Emacs custom-made CI tool will never be as complete, time-tested, maintainted (etc) than a tool that is used by hundred of thousands of users.

No one knows what the future holds.  Aside from that, the point of
getting tested by being "used by hundred of thousands of users" is
moot, especially for Emacs whose users are accustomed to fixing things
themselves ;)

> Also if any of these gitlab/github/etc users want to contribute to Emacs, the time to start being "productive" is very low because they are used to this workflow (and most of them are not used to the mailing list workflow).

Then, they are free to have their own gitlab page, much like when
distros maintain their own set of patches, pending upstream intake.
Additionally, Linux kernel dev has Linux kernel newbies sites, right?

> I think the effort required to understand & use the mailing list workflow is quite significant at the start, then after a while you get used to it... but in my case I'd switch to the gitlab workflow as soon as it is available. It's very likely that others here would switch too if it was available.

My case is certainly the opposite.

> Best regards,
> Philippe

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Ergus]

On Tue, Mar 19, 2019 at 08:27:10AM +0100, Philippe Vaucher wrote:
>>
>> > Sending patches via email is only one requirement.  There are other
>> > requirements peculiar to Emacs, which will not go away if we switch to
>> > another patch submitting system.  Some of these requirements, each and
>> > every one of them flagged at some point as an obstacle for newcomers:
>> >
>> >    . code submissions should include documentation
>> >    . commit log messages should be formatted in a certain way
>> >    . bug numbers should be referenced in log messages
>> >    . US English conventions in writing comments and documentation
>> >      (spelling, two spaces between sentences, etc.)
>> >    . we require copyright assignments for accepting changesets larger
>> >      than about 15 original source lines
>> >    . we have peculiar rules regarding the branch were certain changes
>> >      should be pushed (affects the branch against which contributors
>> >      should prepare patches)
>> >    . very elaborate coding and documenting conventions (their
>> >      description takes around 900 lines in the ELisp manual)
>>
>> At least some of these checks could be automated on a CI. And the author
>> of a random PR would get an overview of its compliance automatically.
>>
>
>Also when someone creates a PR (or Issue), there can be template text (with
>checkboxes, etc) stating these points, so the author has a direct reminder
>to improve the quality of his PR or Issue before he sends it.
>
>And if he does not check all the checboxes and submit anyway, then the
>maintainer's job is easier because he already knows the missing parts.
>
>I believe this whole discussion is basically this: the ones who are used to
>a gitlab workflow see the obvious benefits, and the ones who only use the
>email workflow don't see what's so great about it because they always find
>a manual/configuration-heavy way to achieve the same.
>
>I think the manual/configuration-heavy way is not very smooth and makes
>_you_ work instead of the tools, when this effort could be better spent
>improving Emacs.
>
>Kind regards,
>Philippe

I agree with Philippe and Konstantin. The gitlab interface and workflow
is more attractive for new developers that use to work with
gitlab/bitbuclet/github everyday. On the other hand it will make the
process to report bugs in emacs (from the client side) much easier and
easier to follow. I am refering here to the gitlab installer package.

I already talked to this some months ago. The workflow for pull
requests, interaction between users and feature requests is very sparse
and unfamiliar for young users and developers.

With some minimal corrections the gitlab program could provide backward
compatibility with the mailing list and present the discussions in the
interface as issues OR sent the issues reported in the interface to the
mailing list. So both workflows can be made compatible.

This is something that we could ask to the gitlab developers to
implement (if not already implemented) for our use case and they will be
very pleased to help. (Normally they are)

The alternative is to improve and implement all these things in the
current savannah web interface (or organize it better), but it is like
reinventing the wheel and will require some manpower not available.

The gitlab team could be very interested in providing support to emacs
and other gnu programs because that's a good reputation for the package
and will strengthen them in the competition with github/MS to host free
software. So it is mutual benefit, even if we use only the installer and
not their servers.

My last point is from the normal (not developer) user point of view in
2019. When a normal user finds an issue/bug/feature request it finds
that there is not web interface for that, so he can report the issue
with emacs, but many people don't configure their mail in emacs, they
use thunderbird or web interfaces for that. 

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 19 Mar 2019 02:52:17 +0200
> 
> On 17.03.2019 20:05, Eli Zaretskii wrote:
> >> savannah.gnu.org looks like a news site
> > 
> > Are you sure you are looking at the right page?  You should be looking
> > here:
> > 
> >    https://savannah.gnu.org/projects/emacs
> 
> I can't help but feel that the mentions of Savannah in this thread are 
> disingenuous.

I suggest you to look up the meaning of "disingenuous" before you use
it.  I don't think you really meant that.

In any case, you misunderstood my comment: it was in response to a
claim that Savannah looks like a news site, that's all.

> So since Savannah's role is very minor

See Glenn's response: that Savannah's job is largely behind the scenes
and under the hood doesn't mean its role is minor.  Quite the
contrary.

> >> I've just read a bit about that. I might be missing some nuances of the
> >> process, but right now I don't see how using merge requests vs emails
> >> could interfere.
> > 
> > It doesn't interfere, but it slows down the process for new
> > contributors, so doing this stuff quickly is no longer an attainable
> > goal.
> 
> Wouldn't the said contributors still be able to submit patches over 
> email anyway?

Again, this is orthogonal to what I was saying, as it takes my
comments out of their context.  The issue discussed was the alleged
speed-up of patch contribution process.

> On the other hand, the CI could check all the included commits in a PR 
> for their authors and the copyright assignments of each.  And GitLab 
> would show that this particular check failed, which could be more 
> accessible for a contributor than reading up on patch submission 
> conditions in the documentation.

Surely, each contributor already knows whether they do or don't have
assignment on file?

> >    . code submissions should include documentation
> >    . commit log messages should be formatted in a certain way
> >    . bug numbers should be referenced in log messages
> >    . US English conventions in writing comments and documentation
> >      (spelling, two spaces between sentences, etc.)
> >    . we require copyright assignments for accepting changesets larger
> >      than about 15 original source lines
> >    . we have peculiar rules regarding the branch were certain changes
> >      should be pushed (affects the branch against which contributors
> >      should prepare patches)
> >    . very elaborate coding and documenting conventions (their
> >      description takes around 900 lines in the ELisp manual)
> 
> At least some of these checks could be automated on a CI.

They can also be automated by Git commit hooks.  It's just a matter of
someone doing the job.

And I didn't say I was against adding CI to Emacs, that wasn't at all
the intent of my comments.  I just wanted to make the issue more
complete and balanced, because it isn't as clear-cut as the OP seemed
to indicate in the original message.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 19.03.2019 9:45, Eli Zaretskii wrote:

> I suggest you to look up the meaning of "disingenuous" before you use
> it.  I don't think you really meant that.

Apologies for my choice of words (to Savannah admins especially), but 
the Savannah UI is mostly unused by everybody. And if we're talking 
about user accounts, they are very minimally used as well (e.g. they 
could have been be a part of the bug tracker UI). So what's left is a 
Git server, which is essential, but there are many other available 
alternatives.

Gitlab is a lot more comprehensive and thus unique in its functionality. 
And people are asking for it because of its UI, for the CI, the 
repository browsing, and the issue tracker.

> In any case, you misunderstood my comment: it was in response to a
> claim that Savannah looks like a news site, that's all.

I was also indirectly reacting to RMS's replies, I guess.

> Again, this is orthogonal to what I was saying, as it takes my
> comments out of their context.  The issue discussed was the alleged
> speed-up of patch contribution process.

I think Konstantin was making a point that the PR workflow adds 
opportunities for a speed-up but doesn't take away anything.

And the email workflow would still be available for those who choose it. 
The mailing lists are unlikely to go away.

> Surely, each contributor already knows whether they do or don't have
> assignment on file?

Of course not. Not every potential contributor anyway. Further, if I'm 
reviewing a random patch, *I* don't know if the contribution satisfies 
the CA requirements. If an automatic checking process were available, I 
could just respond with "Thanks!" and merge.

>>>     . code submissions should include documentation
>>>     . commit log messages should be formatted in a certain way
>>>     . bug numbers should be referenced in log messages
>>>     . US English conventions in writing comments and documentation
>>>       (spelling, two spaces between sentences, etc.)
>>>     . we require copyright assignments for accepting changesets larger
>>>       than about 15 original source lines
>>>     . we have peculiar rules regarding the branch were certain changes
>>>       should be pushed (affects the branch against which contributors
>>>       should prepare patches)
>>>     . very elaborate coding and documenting conventions (their
>>>       description takes around 900 lines in the ELisp manual)
>>
>> At least some of these checks could be automated on a CI.
> 
> They can also be automated by Git commit hooks.  It's just a matter of
> someone doing the job.

Hooks can help, but if Emacs doesn't even allow one to *commit* a 
change, it might discourage that person from continuing, or 
investigating the failed requirement. We can add too many checks to 
commit hooks.

Further, documentation could be in a separate commit, so we can't check 
for its presence when running hooks for a commit that adds a change.

And we can't check for copyright assignment inside a git hook because 
the information isn't publicly available.

> And I didn't say I was against adding CI to Emacs, that wasn't at all
> the intent of my comments.  I just wanted to make the issue more
> complete and balanced, because it isn't as clear-cut as the OP seemed
> to indicate in the original message.

I think the core message is sound. He said "easier", not "easy":

"""
migrating to gitlab should make contributions easier for bigger part of 
the open-source world, peoples who used to github and gitlab
"""

I agree with that.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 19 Mar 2019 16:13:53 +0200
> 
> the Savannah UI is mostly unused by everybody.

Savannah UI and Savannah are not identical, far from that.

> Of course not. Not every potential contributor anyway. Further, if I'm 
> reviewing a random patch, *I* don't know if the contribution satisfies 
> the CA requirements. If an automatic checking process were available, I 
> could just respond with "Thanks!" and merge.

Such automated checking is n ot easy to set up, because the copyright
assignment database includes some details that are private and cannot
be exposed to public interfaces.  So someone will have to come up with
a service that publishes only the public parts of that, and even then
there will be some rare cases where a manual check will be needed.

> >> At least some of these checks could be automated on a CI.
> > 
> > They can also be automated by Git commit hooks.  It's just a matter of
> > someone doing the job.
> 
> Hooks can help, but if Emacs doesn't even allow one to *commit* a 
> change, it might discourage that person from continuing, or 
> investigating the failed requirement. We can add too many checks to 
> commit hooks.

It is all too easy to disable/bypass the hooks, as you probably know
very well.  So this doesn't sound like an important issue to me.

> Further, documentation could be in a separate commit

It shouldn't be.

> And we can't check for copyright assignment inside a git hook because 
> the information isn't publicly available.

See above.

> > And I didn't say I was against adding CI to Emacs, that wasn't at all
> > the intent of my comments.  I just wanted to make the issue more
> > complete and balanced, because it isn't as clear-cut as the OP seemed
> > to indicate in the original message.
> 
> I think the core message is sound. He said "easier", not "easy":
> 
> """
> migrating to gitlab should make contributions easier for bigger part of 
> the open-source world, peoples who used to github and gitlab
> """

If that was the only sentence in that message, I probably wouldn't
have responded at all.  The purpose of my response was to provide a
more balanced picture to those who might be unaware of the details.

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Вт, мар 19, 2019 at 9:15 ПП (PM), Eli Zaretskii 
<eliz@gnu.org> написал:
>>  Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
>>  From: Dmitry Gutov <dgutov@yandex.ru>
>>  Date: Tue, 19 Mar 2019 16:13:53 +0200
>> 
>>  the Savannah UI is mostly unused by everybody.
> 
> Savannah UI and Savannah are not identical, far from that.
> 
>>  Of course not. Not every potential contributor anyway. Further, if 
>> I'm
>>  reviewing a random patch, *I* don't know if the contribution 
>> satisfies
>>  the CA requirements. If an automatic checking process were 
>> available, I
>>  could just respond with "Thanks!" and merge.
> 
> Such automated checking is n ot easy to set up, because the copyright
> assignment database includes some details that are private and cannot
> be exposed to public interfaces.  So someone will have to come up with
> a service that publishes only the public parts of that, and even then
> there will be some rare cases where a manual check will be needed.
> 
>>  >> At least some of these checks could be automated on a CI.
>>  >
>>  > They can also be automated by Git commit hooks.  It's just a 
>> matter of
>>  > someone doing the job.
>> 
>>  Hooks can help, but if Emacs doesn't even allow one to *commit* a
>>  change, it might discourage that person from continuing, or
>>  investigating the failed requirement. We can add too many checks to
>>  commit hooks.
> 
> It is all too easy to disable/bypass the hooks, as you probably know
> very well.  So this doesn't sound like an important issue to me.

It looks too easy when you already know how it works. An aribtrary 
newcomer don't.

When a newbie wants to change a code, they don't need to know all 
contribution details, because they're in hacking stage. They're just 
getting acknowledged with the code, they exercise their coding and 
debugging skills. It's the most fragile stage, you don't want to put 
any artifical obstacles here, because there's already a lot of 
unknowns, they may just get overwhelmed.

Btw, Emacs already has at least one git hook, and it's so annoying! The 
hook simply aborts a commit when sees "signed-off-by" message. I'm 
using autocompletion in zsh with `git commit -sv` as last command, so 
it's something I do reflexively. And, while I do appreciate the check 
itself, but having to rewrite a commit message another time isn't nice. 
You might ask me "c'mon, usually there's very little text". Well, while 
that's true most of the time, but for non-native english speaker even 
writing one paragraph may take a bit more effort to do the 
proof-reading, fixing wrong articles, etc. And it's annoying having to 
rewrite that again.

My point is: moving these destructive checks to the moment of the 
actual contribution to upstream (i.e. the gitlab CI that runs for every 
merge-request) would make more pleasant experience for contributors, 
whilst not taking anything from maintainers (sure, "fix unit-test 
failures that your commit caused" is something that a contributor could 
probably figure out themselves).

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Wed, 20 Mar 2019 00:59:41 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, theophilusx@gmail.com,
> 	emacs-devel@gnu.org
> 
> > It is all too easy to disable/bypass the hooks, as you probably know
> > very well.  So this doesn't sound like an important issue to me.
> 
> It looks too easy when you already know how it works. An aribtrary 
> newcomer don't.

I seriously doubt that.  I just now typed into a browser search window
"git bypass commit hooks" and the first hit was exactly what I wanted:

  https://stackoverflow.com/questions/7230820/skip-git-commit-hooks

You will have this as the first hit if you do this from Emacs as well:

  M-s M-w git bypass commit hooks RET

> When a newbie wants to change a code, they don't need to know all 
> contribution details, because they're in hacking stage.

They don't need to know, the commit hook will tell them.  And
bypassing commit hooks is not an Emacs thing, it's a Git thing.

> Btw, Emacs already has at least one git hook, and it's so annoying!

You can disable the hooks locally if you want.

> My point is: moving these destructive checks to the moment of the 
> actual contribution to upstream (i.e. the gitlab CI that runs for every 
> merge-request) would make more pleasant experience for contributors, 
> whilst not taking anything from maintainers (sure, "fix unit-test 
> failures that your commit caused" is something that a contributor could 
> probably figure out themselves).

And my point is that we are once again arguing about very much minor
issues, without doing anything about, nor even touching, the more
important ones.  E.g., I asked up-thread whether you knew how many
people review patches for Emacs; did you follow up on that?  This is
IMO much more important for Emacs development and eventually for its
future than whether our CI will be from Gitlab or from somewhere else,
definitely more important than the commit hooks issue.

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Ср, Mar 20, 2019 at 09:13:11, Eli Zaretskii <eliz@gnu.org> wrote:
>>  My point is: moving these destructive checks to the moment of the
>>  actual contribution to upstream (i.e. the gitlab CI that runs for 
>> every
>>  merge-request) would make more pleasant experience for contributors,
>>  whilst not taking anything from maintainers (sure, "fix unit-test
>>  failures that your commit caused" is something that a contributor 
>> could
>>  probably figure out themselves).
> 
> And my point is that we are once again arguing about very much minor
> issues, without doing anything about, nor even touching, the more
> important ones.  E.g., I asked up-thread whether you knew how many
> people review patches for Emacs; did you follow up on that?  This is
> IMO much more important for Emacs development and eventually for its
> future than whether our CI will be from Gitlab or from somewhere else,
> definitely more important than the commit hooks issue.

I didn't reply this point because I don't know what to add. I get that 
there's not much people doing review, but it's a pain present in most 
projects. Even some Linux kernel subsystems often lacks proper review, 
I regularly see articles about that on LWN popping up — and the 
kernel has thousands of contributors, most of them are paid ones.

Undoubtedly this is important for Emacs future, but where do you think 
new people can appear from? Consider that when I'm talking about 
newbies, I'm implicitly talking about possible future maintainers.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Wed, 20 Mar 2019 09:56:34 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: dgutov@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> 
> > And my point is that we are once again arguing about very much minor
> > issues, without doing anything about, nor even touching, the more
> > important ones.  E.g., I asked up-thread whether you knew how many
> > people review patches for Emacs; did you follow up on that?  This is
> > IMO much more important for Emacs development and eventually for its
> > future than whether our CI will be from Gitlab or from somewhere else,
> > definitely more important than the commit hooks issue.
> 
> I didn't reply this point because I don't know what to add. I get that 
> there's not much people doing review, but it's a pain present in most 
> projects. Even some Linux kernel subsystems often lacks proper review, 
> I regularly see articles about that on LWN popping up — and the 
> kernel has thousands of contributors, most of them are paid ones.

Unlike in many other projects, I consider the situation with patch
review, and more generally with the number of domain experts we have
on board in Emacs, a disaster.

> Undoubtedly this is important for Emacs future, but where do you think 
> new people can appear from?

Yes, this is a bootstrap-type of problem, and such problems can never
be solved by taking care only of some of the aspects in isolation.
Instead, each advance in some aspect must be followed by corresponding
advances in the other aspects, before the next step forward is taken.

Recent years saw a lot of change in Emacs infrastructure and
maintenance procedures -- we moved from CVS to Bazaar to Git, we
removed some of the obstacles to newcomers, such as ChangeLog files,
we codified the most important parts of the procedures in CONTRIBUTE,
etc.  This indeed brought welcome new contributors, but the growth is
very slow, and the impact on the patch review process and on the
number of people who are proficient in core parts of the internals is
still very much minor and inadequate, IMO.  E.g., the backlog in patch
review and in solving reported issues is still unsatisfactory.

So personally, I don't think we are ready for another significant
change in our procedures and infrastructure, not before we give some
more time to these slow tendencies to develop into significant
qualitative changes.  People who want those infrastructure changes
should become more involved, so that we reach the critical mass
sooner.

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> Recent years saw a lot of change in Emacs infrastructure and
> maintenance procedures -- we moved from CVS to Bazaar to Git, we
> removed some of the obstacles to newcomers, such as ChangeLog files,
> we codified the most important parts of the procedures in CONTRIBUTE,
> etc.  This indeed brought welcome new contributors, but the growth is
> very slow, and the impact on the patch review process and on the
> number of people who are proficient in core parts of the internals is
> still very much minor and inadequate, IMO.  E.g., the backlog in patch
> review and in solving reported issues is still unsatisfactory.


It was a nice effort on your part but I feel those changes are unlikely to
really bring a lot of newcomers. Github/Gitlab users want to have things
like this:

https://github.com/bbatsov/projectile/pull/1386
https://github.com/moby/moby/pull/38823
https://github.com/Silex/docker-emacs/pull/24

Things to watch for:

   - Contributions templates (checkboxes, descriptions)
   - Tags/Labels for easier filtering of issues that affect X or Y
   - Inline code review, with code highlighting, which you can then
   "resolve" and push new versions that are hidden by default so you only see
   the latest relevant
   - CI bots that builds & tests your change, report breakage (travis-ci)
   or display code coverage changes (codedov)
   - Tabs at the top for status of the PR, commits, files changed, checks
   done
   - Quickly view modified file history / filtering which files to display
   - Cross referencing of issues

I could go on & on about things that the tool does for you instead of you
having to grep, find-name-dired, find-file, magit-log-buffer-file etc.

With the mailing list the number of things you have to keep in your head or
do manually is huge compared to when using these tools.

Now, I understand that you probably see all this as more work, without any
guarantee that the number of contributors will increase... so you are right
to ask for people wanting these changes to become more involved.

I hope I helped a bit in painting a better picture of why these tools feel
"essential" to us, but they are also tied to a more general
workflow/mindset and that is probably the crux of the issue.

Kind regards,
Philippe

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

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Thu, Mar 21, 2019 at 9:44 AM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>>
>> Recent years saw a lot of change in Emacs infrastructure and
>> maintenance procedures -- we moved from CVS to Bazaar to Git, we
>> removed some of the obstacles to newcomers, such as ChangeLog files,
>> we codified the most important parts of the procedures in CONTRIBUTE,
>> etc.  This indeed brought welcome new contributors, but the growth is
>> very slow, and the impact on the patch review process and on the
>> number of people who are proficient in core parts of the internals is
>> still very much minor and inadequate, IMO.  E.g., the backlog in patch
>> review and in solving reported issues is still unsatisfactory.
>
>
> It was a nice effort on your part but I feel those changes are unlikely to really bring a lot of newcomers. Github/Gitlab users want to have things like this:
>
> https://github.com/bbatsov/projectile/pull/1386
> https://github.com/moby/moby/pull/38823
> https://github.com/Silex/docker-emacs/pull/24
>
> Things to watch for:
>
> Contributions templates (checkboxes, descriptions)
> Tags/Labels for easier filtering of issues that affect X or Y
> Inline code review, with code highlighting, which you can then "resolve" and push new versions that are hidden by default so you only see the latest relevant
> CI bots that builds & tests your change, report breakage (travis-ci) or display code coverage changes (codedov)
> Tabs at the top for status of the PR, commits, files changed, checks done
> Quickly view modified file history / filtering which files to display
> Cross referencing of issues
>
> I could go on & on about things that the tool does for you instead of you having to grep, find-name-dired, find-file, magit-log-buffer-file etc.
>
> With the mailing list the number of things you have to keep in your head or do manually is huge compared to when using these tools.
>
> Now, I understand that you probably see all this as more work, without any guarantee that the number of contributors will increase... so you are right to ask for people wanting these changes to become more involved.
>
> I hope I helped a bit in painting a better picture of why these tools feel "essential" to us, but they are also tied to a more general workflow/mindset and that is probably the crux of the issue.

May I know why instead of an RFE for a migration to have those
features, haven't you already set up one much like what a GNU/Linux
distro usually sets up to collect things pending upstream intake?

Additionally, if some packages are better maintained external to the
core Emacs, why not let them be so rather than trying to bringing them
contributing directly to the core?

> Kind regards,
> Philippe

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> May I know why instead of an RFE for a migration to have those
> features, haven't you already set up one much like what a GNU/Linux
> distro usually sets up to collect things pending upstream intake?
>

I'm sorry but I don't understand this question. We are talking about adding
a gitlab workflow to the existing mailing list workflow so that
gitlab/github users are happier and more prone to contributing. I don't
understand what you are asking about this topic.


Additionally, if some packages are better maintained external to the
> core Emacs, why not let them be so rather than trying to bringing them
> contributing directly to the core?


Again I don't understand what external packages have to do with the topic.
We are not talking about including external packages to core Emacs.

Kind regards,
Philippe

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

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Thu, Mar 21, 2019 at 10:48 AM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>>
>> May I know why instead of an RFE for a migration to have those
>> features, haven't you already set up one much like what a GNU/Linux
>> distro usually sets up to collect things pending upstream intake?
>
>
> I'm sorry but I don't understand this question. We are talking about adding a gitlab workflow to the existing mailing list workflow so that gitlab/github users are happier and more prone to contributing. I don't understand what you are asking about this topic.

You gave the following links as examples that I suppose are intended
to strengthen your argument:
> https://github.com/bbatsov/projectile/pull/1386
> https://github.com/moby/moby/pull/38823
> https://github.com/Silex/docker-emacs/pull/24

AFAIK, those three links have nothing to do with the things that are
discussed in this mailing list, which mostly concerns the Emacs core.

The gitlab workflow that is proposed in this thread, however, is
concerned with the things that are discussed in this mailing list
(Emacs core).  Hence, I expect that the links given as examples would
be about pull requests for things related to Emacs core that had not
been taken upstream by those in this mailing list.

>> Additionally, if some packages are better maintained external to the
>> core Emacs, why not let them be so rather than trying to bringing them
>> contributing directly to the core?
>
>
> Again I don't understand what external packages have to do with the topic. We are not talking about including external packages to core Emacs.

No, we are not talking about including external packages.  Hence, do
you have examples that support your argument that there are people out
there who would contribute to the Emacs core provided that the Emacs
core development adopts the gitlab model?

> Kind regards,
> Philippe

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> >> May I know why instead of an RFE for a migration to have those
> >> features, haven't you already set up one much like what a GNU/Linux
> >> distro usually sets up to collect things pending upstream intake?
> >
> >
> > I'm sorry but I don't understand this question. We are talking about
> adding a gitlab workflow to the existing mailing list workflow so that
> gitlab/github users are happier and more prone to contributing. I don't
> understand what you are asking about this topic.
>
> You gave the following links as examples that I suppose are intended
> to strengthen your argument:
> > https://github.com/bbatsov/projectile/pull/1386
> > https://github.com/moby/moby/pull/38823
> > https://github.com/Silex/docker-emacs/pull/24
>
> AFAIK, those three links have nothing to do with the things that are
> discussed in this mailing list, which mostly concerns the Emacs core.
>

Yes, they are examples about how things are done elsewhere, to illustrate
how things could be if we added the gitlab workflow. I suspect that maybe
many people here don't really realise what the gitlab workflow is or how it
looks, so I wanted to show examples.


The gitlab workflow that is proposed in this thread, however, is
> concerned with the things that are discussed in this mailing list
> (Emacs core).  Hence, I expect that the links given as examples would
> be about pull requests for things related to Emacs core that had not
> been taken upstream by those in this mailing list.
>

Well I cannot show examples of something that does not exist, you cannot do
github/gitlab pull requests to the emacs core, you can only go through the
mailing list (or other non-pull-request means).



> >> Additionally, if some packages are better maintained external to the
> >> core Emacs, why not let them be so rather than trying to bringing them
> >> contributing directly to the core?
> >
> >
> > Again I don't understand what external packages have to do with the
> topic. We are not talking about including external packages to core Emacs.
>
> No, we are not talking about including external packages.  Hence, do
> you have examples that support your argument that there are people out
> there who would contribute to the Emacs core provided that the Emacs
> core development adopts the gitlab model?


Again I cannot have examples of something that does not exist.

As I said earlier, it's possible that adding the gitlab workflow would
yield 0 additional contributors, the only way to know for sure would be to
try it. Personnally I believe that at least for "typo fixes" and tiny
changes you'd get more contributions, because proposing a change on the
gitlab model is trivial (browse to the correct file, click "edit", edit the
file in your browser, press "propose changes", done).

Anway, what I am sure of is that if the gitlab workflow was added there
would be contributors on this ML (including me) that would use it instead
of the mailing list workflow.

If the Emacs maintainers decide not to add the gitlab workflow it's fine by
me, I'm not on a quest to convince everyone. I think you should, but I
understand if you don't.

Kind regards,
Philippe

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Thu, 21 Mar 2019 18:54:32 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Tim Cross <theophilusx@gmail.com>,
> 	Dmitry Gutov <dgutov@yandex.ru>, Konstantin Kharlamov <hi-angel@yandex.ru>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> If the Emacs maintainers decide not to add the gitlab workflow it's fine by me, I'm not on a quest to convince
> everyone. I think you should, but I understand if you don't.

Such significant changes in our processes cannot be done by
"deciding".  It's a large job that needs motivated individuals to do
it.  Doing it also requires first-hand knowledge of our maintenance
procedures and special needs.

So if someone wants to make this happen, I urge you to come on board,
get involved in maintenance, collect some real-life experience in
routine development and maintenance tasks, and then lead the change,
doing most of the work yourself.  And yes, Savannah will most probably
be a large part of the equation, so you will need their cooperation as
well.

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Such significant changes in our processes cannot be done by
> "deciding".  It's a large job that needs motivated individuals to do
> it.  Doing it also requires first-hand knowledge of our maintenance
> procedures and special needs.

I agree. Whatever tooling gets added, it should not get in the way of
how the maintainers work now. They are still doing the hard work and
need to have a workflow that works best for them.

> So if someone wants to make this happen, I urge you to come on board,
> get involved in maintenance, collect some real-life experience in
> routine development and maintenance tasks, and then lead the change,
> doing most of the work yourself.  And yes, Savannah will most probably
> be a large part of the equation, so you will need their cooperation as
> well.

TBH, I've tried this. For years I've been following the mailing list,
and I want to get involved in Emacs development. But I've found it hard
to get around in the codebase.

I'm not sure, but it might be a chicken-and-egg problem. If the tools
are not convenient *for me* to follow-up bugs, review patches, etc., it
will also not help me familiarize with the codebase and
vice-versa. Although that might be an exaggeration, cause I haven't been
finding a lot of time to be actively involved in Emacs development.

But I've been involved in setting up EMBA, cause I believed it might be
the first step towards a "more modern" workflow. If the Emacs community,
and their maintainers, are open to adding such workflow, I'll do my best
to get involved in that too.


-- Toon

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Gcc-Self: nnimap+soverin:Sent
> Date: Tue, 23 Apr 2019 23:19:05 +0200
> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org,
> 	Philippe Vaucher <philippe.vaucher@gmail.com>, dgutov@yandex.ru,
> 	tadeus.prastowo@unitn.it
> 
> > So if someone wants to make this happen, I urge you to come on board,
> > get involved in maintenance, collect some real-life experience in
> > routine development and maintenance tasks, and then lead the change,
> > doing most of the work yourself.  And yes, Savannah will most probably
> > be a large part of the equation, so you will need their cooperation as
> > well.
> 
> TBH, I've tried this. For years I've been following the mailing list,
> and I want to get involved in Emacs development. But I've found it hard
> to get around in the codebase.

Feel free to ask questions and seek guidance here.  "Getting involved"
doesn't mean you need to discover everything on your own, there are
enough knowledgeable and helpful people here who will gladly assist.

> I'm not sure, but it might be a chicken-and-egg problem. If the tools
> are not convenient *for me* to follow-up bugs, review patches, etc., it
> will also not help me familiarize with the codebase and
> vice-versa.

It is possible that you aren't familiar enough with the existing
tools, or haven't set them up optimally.  Once again, feel free to
describe your difficulties here and ask for advice.

It could be that eventually all the advice you get still falls short
of what you want/need, but that kind of conclusion should not be made
before exhausting the existing capabilities.  Familiarity with the
existing tools will also provide better perspective on the relative
importance of improving/changing specific aspects of our process.

> If the Emacs community, and their maintainers, are open to adding
> such workflow

TBH, I don't think I personally understand what "adding such a
workflow" entails.  Maybe I just wasn't following the related
discussions (sorry), or maybe no one described the workflow in enough
detail yet.

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Eli Zaretskii <eliz@gnu.org> writes:

> TBH, I don't think I personally understand what "adding such a
> workflow" entails.  Maybe I just wasn't following the related
> discussions (sorry), or maybe no one described the workflow in enough
> detail yet.

No problem. There has been a lot going on. But you're having a valid
point, people were assuming everyone know what this workflow
entails. Let me briefly describe it.

Instead of email patches, people push their changes in a feature or
topic branch. This usually happens on "fork" of the project (basically a
git clone on the remote system), so the branches will not exist in
canonical repo. Then a so-called Merge Request (or Pull Request) is
created. This feature generates the diff between the topic branch and
the target branch in canonical repo. The maintainers can then review the
changes, add comments at specific lines, or comments in general. The
contributor can address these by pushing changes to the topic
branch. The diff on the Merge Request page will update automatically and
the review cycle can repeat until the maintainer is happy. When they are
happy, they can push a button to apply the changes and the contribution
is done.


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Marcin Borkowski]

On 2019-03-21, at 18:54, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:

> As I said earlier, it's possible that adding the gitlab workflow would
> yield 0 additional contributors, the only way to know for sure would be to
> try it. Personnally I believe that at least for "typo fixes" and tiny
> changes you'd get more contributions, because proposing a change on the
> gitlab model is trivial (browse to the correct file, click "edit", edit the
> file in your browser, press "propose changes", done).
>
> Anway, what I am sure of is that if the gitlab workflow was added there
> would be contributors on this ML (including me) that would use it instead
> of the mailing list workflow.

Hi,

I loosely follow this discussion, but I'm curious: isn't a git branch
workflow equally well supported?  I did contribute a bit to Emacs, and
what i did was push a feature branch and ask for it to be reviewed and
merged.  Not quite what Gitlab does, but closer than sending patches by
email.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: [RFE] Migration to gitlab

[Jean-Christophe Helary]

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



> On Mar 22, 2019, at 19:37, Marcin Borkowski <mbork@mbork.pl> wrote:
> 
> I loosely follow this discussion, but I'm curious: isn't a git branch workflow equally well supported?  I did contribute a bit to Emacs, and what i did was push a feature branch and ask for it to be reviewed and merged.

I'm not totally familiar with git workflows. Would you mind giving more details about how you proceed ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



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

Re: [RFE] Migration to gitlab

[Marcin Borkowski]

On 2019-03-22, at 11:56, Jean-Christophe Helary <brandelune@gmail.com> wrote:

>  On Mar 22, 2019, at 19:37, Marcin Borkowski <mbork@mbork.pl> wrote:
>
>  I loosely follow this discussion, but I'm curious: isn't a git branch workflow equally well supported?  I did contribute a bit to Emacs, and what i did was push a feature branch and ask for it to be reviewed and merged.
>
> I'm not totally familiar with git workflows. Would you mind giving more details about how you proceed ?

Well, what I did was more or less standard, I think: I cloned the Emacs
repo, created a branch, pushed it to the Emacs repo and told everyone on
the ML that a branch is ready to review.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: [RFE] Migration to gitlab

[Jean-Christophe Helary]

> On Mar 23, 2019, at 3:52, Marcin Borkowski <mbork@mbork.pl> wrote:
> 
> Well, what I did was more or less standard, I think: I cloned the Emacs
> repo, created a branch, pushed it to the Emacs repo and told everyone on
> the ML that a branch is ready to review.

Ok, I forgot that you had write access. Then what you describe makes sense.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Пт, Mar 22, 2019 at 13:37:23, Marcin Borkowski <mbork@mbork.pl> 
wrote:
> 
> On 2019-03-21, at 18:54, Philippe Vaucher 
> <philippe.vaucher@gmail.com> wrote:
> 
>>  As I said earlier, it's possible that adding the gitlab workflow 
>> would
>>  yield 0 additional contributors, the only way to know for sure 
>> would be to
>>  try it. Personnally I believe that at least for "typo fixes" and 
>> tiny
>>  changes you'd get more contributions, because proposing a change on 
>> the
>>  gitlab model is trivial (browse to the correct file, click "edit", 
>> edit the
>>  file in your browser, press "propose changes", done).
>> 
>>  Anway, what I am sure of is that if the gitlab workflow was added 
>> there
>>  would be contributors on this ML (including me) that would use it 
>> instead
>>  of the mailing list workflow.
> 
> Hi,
> 
> I loosely follow this discussion, but I'm curious: isn't a git branch
> workflow equally well supported?  I did contribute a bit to Emacs, and
> what i did was push a feature branch and ask for it to be reviewed and
> merged.  Not quite what Gitlab does, but closer than sending patches 
> by
> email.

This might work. I'd be afraid of sending patches on my own that way 
because I don't know an attitude here to "making developers to access 
stuff on unknown sites". But if that's supported, I'd definitely use it.

Is this indeed supported? If yes, can we modify the 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html 
to include such workflow?

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> > I loosely follow this discussion, but I'm curious: isn't a git branch
> > workflow equally well supported?  I did contribute a bit to Emacs, and
> > what i did was push a feature branch and ask for it to be reviewed and
> > merged.  Not quite what Gitlab does, but closer than sending patches
> > by
> > email.
>
> This might work. I'd be afraid of sending patches on my own that way
> because I don't know an attitude here to "making developers to access
> stuff on unknown sites". But if that's supported, I'd definitely use it.


Same here, if I can just point people at my fork or even better directly
push to private branches on the Emacs repo, I would prefer this method
compared to having to generate & send patches by email.

The code review aspect of doing so is not so great tho... the one thing the
ML does right is the ability to inlinecomment the code submited, like what
you can do in a PR on github/gitlab. I understand it'd still be possible
but it then requires the code review guy to do the copy/pasting instead of
the submitter.

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

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Пт, Mar 22, 2019 at 15:38:38, Philippe Vaucher 
<philippe.vaucher@gmail.com> wrote:
>> > I loosely follow this discussion, but I'm curious: isn't a git 
>> branch
>>  > workflow equally well supported?  I did contribute a bit to 
>> Emacs, and
>>  > what i did was push a feature branch and ask for it to be 
>> reviewed and
>>  > merged.  Not quite what Gitlab does, but closer than sending 
>> patches
>>  > by
>>  > email.
>> 
>>  This might work. I'd be afraid of sending patches on my own that way
>>  because I don't know an attitude here to "making developers to 
>> access
>>  stuff on unknown sites". But if that's supported, I'd definitely 
>> use it.
> 
> Same here, if I can just point people at my fork or even better 
> directly push to private branches on the Emacs repo, I would prefer 
> this method compared to having to generate & send patches by email.
> 
> The code review aspect of doing so is not so great tho... the one 
> thing the ML does right is the ability to inlinecomment the code 
> submited, like what you can do in a PR on github/gitlab. I understand 
> it'd still be possible but it then requires the code review guy to do 
> the copy/pasting instead of the submitter.

Ah, good point, I didn't think about it. Then we back to square one.

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> Ah, good point, I didn't think about it. Then we back to square one.

FWIW, I don't mind copy&paste from the *vc-diff* buffer to the email
message: it's a trivial operation compared to the actual review.
And in return I get to use diff-mode (e.g. jump to the source to see
more of the context, ...).

For me the "inconvenience" hurdle is more on the side of getting the
diff out of the branch because depending on the specifics (e.g. where's
the branch, what was the base rev used for the branch, ...), slightly
different commands might be needed.  Nothing that can't be streamlined
with a bit of Elisp hacking, tho.


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Fri, 22 Mar 2019 11:37:23 +0100
> Cc: Tim Cross <theophilusx@gmail.com>, Dmitry Gutov <dgutov@yandex.ru>,
> 	Emacs developers <emacs-devel@gnu.org>,
> 	Konstantin Kharlamov <hi-angel@yandex.ru>,
> 	Tadeus Prastowo <tadeus.prastowo@unitn.it>, Eli Zaretskii <eliz@gnu.org>
> 
> I loosely follow this discussion, but I'm curious: isn't a git branch
> workflow equally well supported?  I did contribute a bit to Emacs, and
> what i did was push a feature branch and ask for it to be reviewed and
> merged.  Not quite what Gitlab does, but closer than sending patches by
> email.

You can only push a branch to the Emacs repository if you have write
access.  Most infrequent contributors don't.

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> You can only push a branch to the Emacs repository if you have write
> access.  Most infrequent contributors don't.

But we could accept people sending an email with a URL to a branch in
their own repository.  I'm not sure how conveniently Git handles that
(ideally, I'd like to be able to do something like "git diff URL"), but
we could in any case add a VC command to do that.


        Stefan

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Пт, Mar 22, 2019 at 16:50:51, Stefan Monnier 
<monnier@iro.umontreal.ca> wrote:
>>  You can only push a branch to the Emacs repository if you have write
>>  access.  Most infrequent contributors don't.
> 
> But we could accept people sending an email with a URL to a branch in
> their own repository.  I'm not sure how conveniently Git handles that
> (ideally, I'd like to be able to do something like "git diff URL"), 
> but
> we could in any case add a VC command to do that.

Well, you need to fetch the repo locally, then you can do:

	git log upstream/master.. # to see new commits added here compared to 
master. Add `-p` to see the code too.

I also added a git alias l = "log --format=\"%ad %an, 
%h:\t^[[34m%s^[[0m\"", so I do `git l upstream/master..` to see a 
convenient shortlog.

----

Thanks, FTR, I'll report a bug on git-send creating separate threads, 
but a bit later: this evening or tomorrow.

Re: [RFE] Migration to gitlab

[Teemu Likonen]

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

Stefan Monnier [2019-03-22 09:50:51-04] wrote:

> But we could accept people sending an email with a URL to a branch in
> their own repository.  I'm not sure how conveniently Git handles that
> (ideally, I'd like to be able to do something like "git diff URL"), but
> we could in any case add a VC command to do that.

"git pull" is actually "git fetch" + "git merge" so to check a remote
repository one would do "git fetch https://...". Then useful comands
would be

git diff master...FETCH_HEAD  # from branches' common base to FETCH_HEAD
git diff master FETCH_HEAD    # between the brances
git log -p master..FETCH_HEAD # log+patches from the common base to FETCH_HEAD

If FETCH_HEAD from a remote url is not merged or turned into a named
branch the new git objects will eventually be garbage collected.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

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

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>> But we could accept people sending an email with a URL to a branch in
>> their own repository.  I'm not sure how conveniently Git handles that
>> (ideally, I'd like to be able to do something like "git diff URL"), but
>> we could in any case add a VC command to do that.
> "git pull" is actually "git fetch" + "git merge" so to check a remote
> repository one would do "git fetch https://...". Then useful comands
> would be
>
> git diff master...FETCH_HEAD  # from branches' common base to FETCH_HEAD
> git diff master FETCH_HEAD    # between the brances
> git log -p master..FETCH_HEAD # log+patches from the common base to FETCH_HEAD

Ah FETCH_HEAD sounds like the solution to avoid having to `git remote add`.
Cool, thanks!

So, yes, this sounds like a nice alternative that avoids the need to
have write access to emacs.git.


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Date: Fri, 22 Mar 2019 16:20:08 +0200
> Cc: emacs-devel@gnu.org
> 
> "git pull" is actually "git fetch" + "git merge" so to check a remote
> repository one would do "git fetch https://...". Then useful comands
> would be
> 
> git diff master...FETCH_HEAD  # from branches' common base to FETCH_HEAD
> git diff master FETCH_HEAD    # between the brances
> git log -p master..FETCH_HEAD # log+patches from the common base to FETCH_HEAD
> 
> If FETCH_HEAD from a remote url is not merged or turned into a named
> branch the new git objects will eventually be garbage collected.

Would people want to fetch from a random machine out there just to
review a patch submission?  I'm not sure.

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>> "git pull" is actually "git fetch" + "git merge" so to check a remote
>> repository one would do "git fetch https://...". Then useful comands
>> would be
>> 
>> git diff master...FETCH_HEAD  # from branches' common base to FETCH_HEAD
>> git diff master FETCH_HEAD    # between the brances
>> git log -p master..FETCH_HEAD # log+patches from the common base to FETCH_HEAD
>> 
>> If FETCH_HEAD from a remote url is not merged or turned into a named
>> branch the new git objects will eventually be garbage collected.
>
> Would people want to fetch from a random machine out there just to
> review a patch submission?  I'm not sure.

I know I would and can't see why other people wouldn't.

I expect it's safer to "git fetch + git diff" from a random machine out
there than it is to have your MUA process a random email from
a random person.

Clearly, it requires to be connected in order to fetch the branch
(rather than having the patch fetched when you sync your email), but you
can still review it offline after that.


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 22 Mar 2019 11:19:26 -0400
> 
> > Would people want to fetch from a random machine out there just to
> > review a patch submission?  I'm not sure.
> 
> I know I would and can't see why other people wouldn't.

Ok, so if enough people who review patches would like that, we could
support such a procedure as well.

> I expect it's safer to "git fetch + git diff" from a random machine out
> there than it is to have your MUA process a random email from
> a random person.

Really?  Doesn't the mail server from which I fetch email do something
to protect me?

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>> I expect it's safer to "git fetch + git diff" from a random machine out
>> there than it is to have your MUA process a random email from
>> a random person.
> Really?  Doesn't the mail server from which I fetch email do something
> to protect me?

It probably runs some anti-virus scanner.  If you believe in anti-virus
scanners, then maybe you'll count that as improving your security a bit.

But it's not like Git doesn't do its due diligence in sanity checking.
And "git diff" can't generate a malware attachment (it can spew junk
but that should be no more harmful than if it were attached to an
email).

It's not like I completely trust in Git's C code, but since that same
code is used by many Git servers, I think it's likely that it's been
reasonably scrutinized and is at least as safe as your MUA (probably
safer than any Elisp MUA).


        Stefan

Re: [RFE] Migration to gitlab

[Juri Linkov]

>> But we could accept people sending an email with a URL to a branch in
>> their own repository.  I'm not sure how conveniently Git handles that
>> (ideally, I'd like to be able to do something like "git diff URL"), but
>> we could in any case add a VC command to do that.
>
> "git pull" is actually "git fetch" + "git merge" so to check a remote
> repository one would do "git fetch https://...". Then useful comands
> would be
>
> git diff master...FETCH_HEAD  # from branches' common base to FETCH_HEAD
> git diff master FETCH_HEAD    # between the brances
> git log -p master..FETCH_HEAD # log+patches from the common base to FETCH_HEAD

In bug#33950 we are creating a vc command for this, but the problem is in
Git inconsistency: it uses 3 dots for diff, and 2 dots for log.

> If FETCH_HEAD from a remote url is not merged or turned into a named
> branch the new git objects will eventually be garbage collected.

I didn't know about FETCH_HEAD because vc-git doesn't show it in the
completion list that contains only HEAD.  Maybe FETCH_HEAD should be
added to vc-git-revision-table as well?

What other useful ref names are provided by git?

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 22 Mar 2019 09:50:51 -0400
> 
> > You can only push a branch to the Emacs repository if you have write
> > access.  Most infrequent contributors don't.
> 
> But we could accept people sending an email with a URL to a branch in
> their own repository.

How would I then send the results of my review of the changes?  If
this is convenient enough, and doesn't involve any security risks, we
could support such a possibility, sure.  But before we make the
decision, we need to think the entire workflow through, starting from
the initial submission, through all the followup changes, and ending
with pushing the changes, and see that these all can be easily
supported from Emacs and Git.

Re: [RFE] Migration to gitlab

[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 should not have code in our repository whose copyright has not been
assigned.  So we need to be careful about who can put code into it,
even if it is in a "personal" branch.

There are other potential problems with a "personal" branch.
For instance, it might recommend nonfree software.
Keeping things on the right track is part of the package maintainers'
responsibility, but if they don't do this for "personal" branches,
in effect we are giving every contributot maintainer responibilities
without their saying they accept those responibilities.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: mbork@mbork.pl, theophilusx@gmail.com, dgutov@yandex.ru,
> 	emacs-devel@gnu.org, philippe.vaucher@gmail.com,
> 	hi-angel@yandex.ru, tadeus.prastowo@unitn.it
> Date: Fri, 22 Mar 2019 22:33:56 -0400
> 
> We should not have code in our repository whose copyright has not been
> assigned.  So we need to be careful about who can put code into it,
> even if it is in a "personal" branch.

I don't think we have "personal branches" in our repository.  All the
branches there are public branches, and their legal status is the same
as of any other branch, including the master branch.

Or maybe I don't understand what you meant by "a personal branch".

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Сб, мар 23, 2019 at 10:18 ДП (AM), Eli Zaretskii 
<eliz@gnu.org> написал:
>>  From: Richard Stallman <rms@gnu.org>
>>  Cc: mbork@mbork.pl, theophilusx@gmail.com, dgutov@yandex.ru,
>>  	emacs-devel@gnu.org, philippe.vaucher@gmail.com,
>>  	hi-angel@yandex.ru, tadeus.prastowo@unitn.it
>>  Date: Fri, 22 Mar 2019 22:33:56 -0400
>> 
>>  We should not have code in our repository whose copyright has not 
>> been
>>  assigned.  So we need to be careful about who can put code into it,
>>  even if it is in a "personal" branch.
> 
> I don't think we have "personal branches" in our repository.  All the
> branches there are public branches, and their legal status is the same
> as of any other branch, including the master branch.
> 
> Or maybe I don't understand what you meant by "a personal branch".

I think he was talking about the gitlab workflow.

I didn't do copyright assignment, but it sounds simple. I think on 
gitlab login page it could have be implemented with a few checkboxes 
for registration, thus ensuring that every new user has it.

Btw, how do I do it? Do I have to create a separate topic in 
emacs-devel at the moment? (that's how I read docs here 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Copyright-Assignment.html#Copyright-Assignment 
)

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sat, 23 Mar 2019 17:04:50 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: rms@gnu.org, mbork@mbork.pl, theophilusx@gmail.com, dgutov@yandex.ru,
> 	emacs-devel@gnu.org, philippe.vaucher@gmail.com, tadeus.prastowo@unitn.it
> 
> I didn't do copyright assignment, but it sounds simple. I think on 
> gitlab login page it could have be implemented with a few checkboxes 
> for registration, thus ensuring that every new user has it.

Assigning copyright involves filling and sending a form to the FSF
copyright clerk, then receiving the assignment contract, signing it,
and returning it to the FSF.  I'm not sure I understand how a single
checkbox could do this.

> Btw, how do I do it?

You ask me for the form to fill, or download it yourself.  Then you
fill the form and email the filled form according to the instructions
that come with the form.  Then you wait for the FSF clerk to prepare
the assignment contract and send it to you.  Then you sign the
contract and send it back.  Then the FSF clerk sends you a copy of the
contract signed both by you and by the FSF.  And then it's done.

Re: [RFE] Migration to gitlab

[Van L]

>> Btw, how do I do it?
>
> You ask me for the form to fill, or download it yourself.  Then you
> fill the form and email the filled form according to the instructions
> that come with the form.  Then you wait for the FSF clerk to prepare
> the assignment contract and send it to you.  Then you sign the
> contract and send it back.  Then the FSF clerk sends you a copy of the
> contract signed both by you and by the FSF.  And then it's done.

And, the procedure is paperless? no scanner, no printer needed.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

On March 24, 2019 8:29:07 AM GMT+02:00, Van L <van@scratch.space> wrote:
> >> Btw, how do I do it?
> >
> > You ask me for the form to fill, or download it yourself.  Then you
> > fill the form and email the filled form according to the
> instructions
> > that come with the form.  Then you wait for the FSF clerk to prepare
> > the assignment contract and send it to you.  Then you sign the
> > contract and send it back.  Then the FSF clerk sends you a copy of
> the
> > contract signed both by you and by the FSF.  And then it's done.
> 
> And, the procedure is paperless? no scanner, no printer needed.

In some countries, yes.  But those are the minority, AFAIK.  The FSF clerk will tell in each case how to proceed.

Re: [RFE] Migration to gitlab

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

  > I don't think we have "personal branches" in our repository.

I don't think so either.  Someone argued for allowing them,
so I argued against the proposal.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Ср, Mar 20, 2019 at 10:23:08, Eli Zaretskii <eliz@gnu.org> wrote:
>>  Date: Wed, 20 Mar 2019 09:56:34 +0300
>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>  Cc: dgutov@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
>> 
>>  > And my point is that we are once again arguing about very much 
>> minor
>>  > issues, without doing anything about, nor even touching, the more
>>  > important ones.  E.g., I asked up-thread whether you knew how many
>>  > people review patches for Emacs; did you follow up on that?  This 
>> is
>>  > IMO much more important for Emacs development and eventually for 
>> its
>>  > future than whether our CI will be from Gitlab or from somewhere 
>> else,
>>  > definitely more important than the commit hooks issue.
>> 
>>  I didn't reply this point because I don't know what to add. I get 
>> that
>>  there's not much people doing review, but it's a pain present in 
>> most
>>  projects. Even some Linux kernel subsystems often lacks proper 
>> review,
>>  I regularly see articles about that on LWN popping up — and the
>>  kernel has thousands of contributors, most of them are paid ones.
> 
> Unlike in many other projects, I consider the situation with patch
> review, and more generally with the number of domain experts we have
> on board in Emacs, a disaster.

FTR, I think one reason that not many people are doing review is the 
requirement for patches to be sent to bugtracker. Besides being just 
confusing (obviously, it's a hack to work around lack of patch-tracking 
system on emacs-devel), this conflicts with the fact, that contributors 
are more likely to be subscribed to devel list rather than to 
bugtracker.

For example, I'm not subscribed to bugtracker because I don't know 
Emacs internals to give any useful comment for bugs. But at least for 
*.c file changes I could help a bit with review if I saw something on 
ML.

If you (not you personally, but Emacs developers) are trying to use 
mailing list workflow, you might want to copy some parts of it from 
other projects, such as Mesa drivers. Ignoring for a second the fact 
that Mesa partially moved to gitlab, for ML part they used α) 
patchwork site to keep track of patches on mesa-devel, and β) 
bugtracker notifications go to mesa-devel ML, so 
contributors/developers see them.

And while on it, a few weeks ago I sent 2 patches to bugtrackers, and I 
got a notification for each of them. I'm horrified to imagine what I 
gonna see if I send a series of 20 patches.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Fri, 22 Mar 2019 13:01:58 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: dgutov@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> 
> FTR, I think one reason that not many people are doing review is the 
> requirement for patches to be sent to bugtracker. Besides being just 
> confusing (obviously, it's a hack to work around lack of patch-tracking 
> system on emacs-devel), this conflicts with the fact, that contributors 
> are more likely to be subscribed to devel list rather than to 
> bugtracker.
> 
> For example, I'm not subscribed to bugtracker because I don't know 
> Emacs internals to give any useful comment for bugs. But at least for 
> *.c file changes I could help a bit with review if I saw something on 
> ML.

You don't need to be subscribed to bug-gnu-emacs mailing list
(although if you are interested in helping the development, I would
recommend subscribing).  You can instead point your Web browser to
https://debbugs.gnu.org/ and use the various filtering options there.
Or you could use the debbugs package in ELPA to do that.

In addition, there's the emacs-diffs mailing list, where you can see
the commits going in.

Finally, being subscribed to the bug list doesn't mean you should feel
obligated to respond to reports where you have nothing useful to say.
You can respond only to messages of your choice, and disregard the
rest.

> If you (not you personally, but Emacs developers) are trying to use 
> mailing list workflow, you might want to copy some parts of it from 
> other projects, such as Mesa drivers. Ignoring for a second the fact 
> that Mesa partially moved to gitlab, for ML part they used α) 
> patchwork site to keep track of patches on mesa-devel, and β) 
> bugtracker notifications go to mesa-devel ML, so 
> contributors/developers see them.

The emacs-devel mailing list is too high-volume to add the bug traffic
to it.  We currently have an average of about 40 to 50 messages per
day; adding the bugs will almost double that, and prevent people who
are not interested in bugs to be involved in the development
discussions.  having two lists means each one can decide whether they
want to see both streams or just one.

> And while on it, a few weeks ago I sent 2 patches to bugtrackers, and I 
> got a notification for each of them. I'm horrified to imagine what I 
> gonna see if I send a series of 20 patches.

There's no requirement in Emacs development to send patches in series,
you can send a single patch for the entire changeset.  then you will
get only one notification.

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Пт, Mar 22, 2019 at 13:16:56, Eli Zaretskii <eliz@gnu.org> wrote:
>>  And while on it, a few weeks ago I sent 2 patches to bugtrackers, 
>> and I
>>  got a notification for each of them. I'm horrified to imagine what I
>>  gonna see if I send a series of 20 patches.
> 
> There's no requirement in Emacs development to send patches in series,
> you can send a single patch for the entire changeset.  then you will
> get only one notification.

This is odd, why would I do that? If somebody would squash 20 commits 
into just one, and sent me for review, "break commits by functional" 
would be my very first comment. How a reviewer supposed to give any 
useful comments besides high-level stuff like "remove the commented out 
code there", if a sigle patch does 20 functionally different changes?

Furthermore: if such patch was commited, how other developers in the 
future, while studying the git-log, are supposed to make any sense of 
this commit?

And how one supposed to git-bisect a regression with such a commit?

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Fri, 22 Mar 2019 13:34:48 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: dgutov@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> 
> > There's no requirement in Emacs development to send patches in series,
> > you can send a single patch for the entire changeset.  then you will
> > get only one notification.
> 
> This is odd, why would I do that?

You don't _have_ to.  I'm saying that you _can_ if that makes things
easier for you.

> If somebody would squash 20 commits into just one, and sent me for
> review, "break commits by functional" would be my very first
> comment.

You won't hear such comments here.  This is not one of the projects to
which you are used, this is Emacs.

> How a reviewer supposed to give any useful comments besides
> high-level stuff like "remove the commented out code there", if a
> sigle patch does 20 functionally different changes?

I was talking about a single changeset, i.e. a set of changes that fix
a particular problem or introduce a particular single feature.  The
rules for deciding what should be in a single changeset and what
should be split between several ones are unaffected by what I said;
the point is that you can submit changes for a single changeset as a
single patch.

If you do submit a single coherent changeset, trust me and others here
that we will be able to review it.  It's not your problem as a
submitter.

OTOH, submitting in a single submission to a single bug report a patch
series which constitute more than a single changeset _will_ get you
responses saying to break that into several unrelated reports and
series.

> Furthermore: if such patch was commited, how other developers in the 
> future, while studying the git-log, are supposed to make any sense of 
> this commit?
> 
> And how one supposed to git-bisect a regression with such a commit?

We do that all the time.  Many (most) of the contributors rebase their
changes on the latest master anyway, so this has to be dealt with
regardless of how you submit the patches.  E.g., most of those who
create public feature branches in the Emacs repository will rebase
before landing the feature, thus making bisection inside the branch
development very hard at best.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 22.03.2019 12:16, Eli Zaretskii wrote:

> You don't need to be subscribed to bug-gnu-emacs mailing list
> (although if you are interested in helping the development, I would
> recommend subscribing).  You can instead point your Web browser to
> https://debbugs.gnu.org/ and use the various filtering options there.
> Or you could use the debbugs package in ELPA to do that.

Should I add some examples of how more modern bug trackers make it 
easier and more enticing for a random person to contribute?

> Finally, being subscribed to the bug list doesn't mean you should feel
> obligated to respond to reports where you have nothing useful to say.
> You can respond only to messages of your choice, and disregard the
> rest.

For one thing, if you're not subscribed to the list, replying to a 
particular message is more difficult (you have to copy the subject and 
the addresses), and the result will break out of an existing thread for 
everybody involved.

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>> https://debbugs.gnu.org/ and use the various filtering options there.
[...]
> For one thing, if you're not subscribed to the list, replying to
> a particular message is more difficult (you have to copy the subject and the
> addresses), and the result will break out of an existing thread for
> everybody involved.

Indeed, M-x gnus-read-ephemeral-emacs-bug-group RET is a much better
option to read a particular bug report (and reply to it).
Of course, it assumes your Emacs's smtpmail.el is properly configured to
send the reply.


        Stefan

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 22.03.2019 16:57, Stefan Monnier wrote:

> Indeed, M-x gnus-read-ephemeral-emacs-bug-group RET is a much better
> option to read a particular bug report (and reply to it).

Indeed, that works better if one is used to Gnus. I've tried it for a 
few years then went back to Thunderbird for a number of reasons.

And I don't think we should expect all our contributors to have a MUA 
configured in a particular way.

> Of course, it assumes your Emacs's smtpmail.el is properly configured to
> send the reply.

Yup. That stopped being the case for me when Google added 
per-application passwords.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 Mar 2019 16:36:58 +0200
> 
> On 22.03.2019 12:16, Eli Zaretskii wrote:
> 
> > You don't need to be subscribed to bug-gnu-emacs mailing list
> > (although if you are interested in helping the development, I would
> > recommend subscribing).  You can instead point your Web browser to
> > https://debbugs.gnu.org/ and use the various filtering options there.
> > Or you could use the debbugs package in ELPA to do that.
> 
> Should I add some examples of how more modern bug trackers make it 
> easier and more enticing for a random person to contribute?

If you want.  Though it isn't necessarily related to the point I was
trying to make, which was in response to a very specific comment made
by Konstantin.

> For one thing, if you're not subscribed to the list, replying to a 
> particular message is more difficult (you have to copy the subject and 
> the addresses), and the result will break out of an existing thread for 
> everybody involved.

First, I did recommend to subscribe.  But if one doesn't subscribe,
there's still a way to reply properly, albeit a bit convoluted: you
can download each of the messages recorded by the bug tracker as an
mbox file (the link to do that is shown as part of the header of each
message when you read the bug discussions in a web browser), then tell
your MUA to read that mbox file, and reply to the message.

(You can also download each month of the traffic on bug-gnu-emacs as
an mbox file, the link is shown when you read the list archives in a
browser.)

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> And while on it, a few weeks ago I sent 2 patches to bugtrackers, and I got a
> notification for each of them. I'm horrified to imagine what I gonna see if I
> send a series of 20 patches.

Are you referring to the tracker's acknowledgment emails? 
If so, it's possible to opt out of them; see
https://debbugs.gnu.org/Reporting.html and admin/notes/bugtracker:

To not get acknowledgment mail from the tracker, add an
"X-Debbugs-No-Ack:" header (with any value).  If you use Gnus, you can
add an element to gnus-posting-styles to do this automatically, eg:

("gnu-emacs\\(-pretest\\)?-bug"
   ("X-Debbugs-No-Ack" "yes"))

(adjust the regexp according to the name you use for the bug lists)

-- 
Basil

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> And while on it, a few weeks ago I sent 2 patches to bugtrackers, and I got
> a notification for each of them. I'm horrified to imagine what I gonna see
> if I send a series of 20 patches.

If the 20 email messages are properly threaded (i.e. with In-Reply-To
headers), then debbugs.gnu.org should be able to only create a single
bug nb for them, so you should only receive 1 notification instead
of 20.

BTW: I'm not subscribed to the bug list (and with no intention to
subscribe to it again in the foreseeable future), but I would subscribe
to a "submitted patches" mailing list.


        Stefan

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

On Пт, Mar 22, 2019 at 16:05:32, Stefan Monnier 
<monnier@iro.umontreal.ca> wrote:
>>  And while on it, a few weeks ago I sent 2 patches to bugtrackers, 
>> and I got
>>  a notification for each of them. I'm horrified to imagine what I 
>> gonna see
>>  if I send a series of 20 patches.
> 
> If the 20 email messages are properly threaded (i.e. with In-Reply-To
> headers), then debbugs.gnu.org should be able to only create a single
> bug nb for them, so you should only receive 1 notification instead
> of 20.

Well, I've sent the patches with plain `git send-email`, and I got the 
2 notifcations, so I guess it doesn't set them properly. Then again, 
`git send-email` AFAIK is the most popular way of sending patches to 
mailing lists, so I assume by default everyone gonna get separate 
notifications for every patch.

> BTW: I'm not subscribed to the bug list (and with no intention to
> subscribe to it again in the foreseeable future), but I would 
> subscribe
> to a "submitted patches" mailing list.
> 
> 
>         Stefan
> 
> 

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> Well, I've sent the patches with plain `git send-email`, and I got the
> 2 notifcations, so I guess it doesn't set them properly.

Sounds like a bug in out debbugs code, then.
Can you `M-x report-emacs-bug` about that?  Regardless of notifications,
we don't want to open 20 new bug reports when you do a single `git send-mail`.


        Stefan

Re: [RFE] Migration to gitlab

[Glenn Morris]

Stefan Monnier wrote:

> Can you `M-x report-emacs-bug` about that?

Please try to remember to always prefix that with "Search for an
existing bug report about that, and if you don't find one then...".

This is https://debbugs.gnu.org/15361.
I don't think the current discussion is adding anything new.

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>> Can you `M-x report-emacs-bug` about that?
> Please try to remember to always prefix that with "Search for an
> existing bug report about that, and if you don't find one then...".

Arguably `M-x report-emacs-bug` should do that.

> This is https://debbugs.gnu.org/15361.

Ah, right.  I see that Stefan even opined there already.
He always gets there before I do, damn bastard!


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 22 Mar 2019 09:05:32 -0400
> 
> BTW: I'm not subscribed to the bug list (and with no intention to
> subscribe to it again in the foreseeable future), but I would subscribe
> to a "submitted patches" mailing list.

How would that mailing list be different from bug-gnu-emacs@gnu.org?
I'm not against such a list, but I don't see the difference between
these two.  Are you saying you'd like to see patches without the bug
report which led to them, for example?  Or without the discussion that
follows the proposed patch?

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> How would that mailing list be different from bug-gnu-emacs@gnu.org?

It would not contain bug reports but patches.  Just like on those web
interfaces they have "issues" and "pull requests": even though the two
can be technically identical, the intention is different.

> these two.  Are you saying you'd like to see patches without the bug
> report which led to them, for example?  Or without the discussion that
> follows the proposed patch?

Rather, I don't want to see the bug reports until there's a suggested
patch for them.  At that point I may very well want to go back to the
discussion that lead to it in order to better understand the intention
behind the patch, of course.


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 22 Mar 2019 09:48:20 -0400
> 
> > Are you saying you'd like to see patches without the bug report
> > which led to them, for example?  Or without the discussion that
> > follows the proposed patch?
> 
> Rather, I don't want to see the bug reports until there's a suggested
> patch for them.  At that point I may very well want to go back to the
> discussion that lead to it in order to better understand the intention
> behind the patch, of course.

That sounds like filtering would be a better solution than separation
into two mailing lists.  Doesn't debbugs inject some header into
messages with a patch?  If not, perhaps it should.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 22.03.2019 16:37, Eli Zaretskii wrote:

> That sounds like filtering would be a better solution than separation
> into two mailing lists.  Doesn't debbugs inject some header into
> messages with a patch?  If not, perhaps it should.

How would it differentiate simple bug reports from bug reports with 
inline patches, for example?

And if you're talking about somebody doing the tagging manually 
post-factum, that won't work great because the original email was 
already filtered out by whatever system Stefan could set up.

I don't really see how you could make it work well with an email-based 
workflow without a separate mailing list or similar.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 Mar 2019 16:50:23 +0200
> 
> On 22.03.2019 16:37, Eli Zaretskii wrote:
> 
> > That sounds like filtering would be a better solution than separation
> > into two mailing lists.  Doesn't debbugs inject some header into
> > messages with a patch?  If not, perhaps it should.
> 
> How would it differentiate simple bug reports from bug reports with 
> inline patches, for example?

I don't know.  Maybe it cannot.  Which means the solution is not
perfect, but it doesn't mean it's totally useless, because it does
improve the current situation to some extent.

> I don't really see how you could make it work well with an email-based 
> workflow without a separate mailing list or similar.

A separate mailing list will make patch review much less convenient,
because it will require the reviewer to read and respond to two
different threads on two different lists.  So I would object to such a
change.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 22.03.2019 17:31, Eli Zaretskii wrote:

> I don't know.  Maybe it cannot.  Which means the solution is not
> perfect, but it doesn't mean it's totally useless, because it does
> improve the current situation to some extent.

Sometimes a less-than-accurate solution feels worse than a no solution. 
To me, at least.

> A separate mailing list will make patch review much less convenient,
> because it will require the reviewer to read and respond to two
> different threads on two different lists.  So I would object to such a
> change.

TBH, that was me still making a case against an email-based workflow 
altogether.

More to come later (hopefully, something more helpful).

Re: [RFE] Migration to gitlab

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Rather, I don't want to see the bug reports until there's a suggested
>> patch for them.  At that point I may very well want to go back to the
>> discussion that lead to it in order to better understand the intention
>> behind the patch, of course.
>
> That sounds like filtering would be a better solution than separation
> into two mailing lists.  Doesn't debbugs inject some header into
> messages with a patch?  If not, perhaps it should.

Don't know. But we have the "patch" tag in debbugs, which should be set
automatically, when a message arrives sent from git-patch. IIRC, this
tag must be set manually today.

And with that tag, you could filter easily the bugs. Either on the
debbugs.gnu.org site, or with the debbugs package:

--8<---------------cut here---------------start------------->8---
(let ((debbugs-gnu-current-suppress t))
  (debbugs-gnu nil '("emacs") nil nil '("patch")))
--8<---------------cut here---------------end--------------->8---

shows you all 196 open Emacs bugs, which have the "patch" tag.

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Fri, 22 Mar 2019 17:23:42 +0100
> 
> > That sounds like filtering would be a better solution than separation
> > into two mailing lists.  Doesn't debbugs inject some header into
> > messages with a patch?  If not, perhaps it should.
> 
> Don't know. But we have the "patch" tag in debbugs, which should be set
> automatically, when a message arrives sent from git-patch. IIRC, this
> tag must be set manually today.

What can we do to cause it to be set automatically?  Submit a debbugs
feature request?

Re: [RFE] Migration to gitlab

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Don't know. But we have the "patch" tag in debbugs, which should be set
>> automatically, when a message arrives sent from git-patch. IIRC, this
>> tag must be set manually today.
>
> What can we do to cause it to be set automatically?  Submit a debbugs
> feature request?

Likely yes. But let's check first the status; maybe I'm wrong. Maybe
it's implemented already upstream.

A debbugs feature request will be the right approach, but it will take
time. Even when it is acceppted upstream by the debbugs people, we
should implement it ourselves, and offer this upstream.

And then we have the problem to sync debbugs.gnu.org with upstream
debbugs software; which is a stalled task. I really miss Noam ... achhhhh.

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 22 Mar 2019 17:48:10 +0100
> 
> I really miss Noam ... achhhhh.

Seconded.

Re: [RFE] Migration to gitlab

[Glenn Morris]

Michael Albinus wrote:

> Don't know. But we have the "patch" tag in debbugs, which should be set
> automatically, when a message arrives sent from git-patch.

FYI [PATCH] in the subject is treated the same as "Tags: patch".

Re: [RFE] Migration to gitlab

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

Hi Glenn,

>> Don't know. But we have the "patch" tag in debbugs, which should be set
>> automatically, when a message arrives sent from git-patch.
>
> FYI [PATCH] in the subject is treated the same as "Tags: patch".

Thanks, I didn't know (or I did, and forgot). Maybe it's worth to
mention this in admin/notes/bugtracker?

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Fri, 22 Mar 2019 17:57:31 +0100
> 
> Maybe it's worth to mention this in admin/notes/bugtracker?

In CONTRIBUTE, I think.

Re: [RFE] Migration to gitlab

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Maybe it's worth to mention this in admin/notes/bugtracker?
>
> In CONTRIBUTE, I think.

It isn't necessary there. The description how to create a message
including a patch does already ensures the keyword "[PATCH]" in the
message subject line, due to "git format-patch ...".

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: rgm@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 24 Mar 2019 14:53:19 +0100
> 
> >> Maybe it's worth to mention this in admin/notes/bugtracker?
> >
> > In CONTRIBUTE, I think.
> 
> It isn't necessary there. The description how to create a message
> including a patch does already ensures the keyword "[PATCH]" in the
> message subject line, due to "git format-patch ...".

But not everyone uses "git format-patch", and using it is not
mandatory, just encouraged.

Re: [RFE] Migration to gitlab

[Michael Albinus]

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

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> >> Maybe it's worth to mention this in admin/notes/bugtracker?
>> >
>> > In CONTRIBUTE, I think.
>>
>> It isn't necessary there. The description how to create a message
>> including a patch does already ensures the keyword "[PATCH]" in the
>> message subject line, due to "git format-patch ...".
>
> But not everyone uses "git format-patch", and using it is not
> mandatory, just encouraged.

Like this?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff, Size: 1129 bytes --]

*** /tmp/ediffYbcrob	2019-03-25 17:26:15.099153743 +0100
--- /home/albinus/src/emacs/CONTRIBUTE	2019-03-25 17:25:57.710880544 +0100
***************
*** 59,65 ****
  The Emacs issue tracker at https://debbugs.gnu.org lets you view bug
  reports and search the database for bugs matching several criteria.
  Messages posted to the bug-gnu-emacs@gnu.org mailing list, mentioned
! above, are recorded by the tracker with the corresponding bugs/issues.

  GNU ELPA has a 'debbugs' package that allows accessing the tracker
  database from Emacs.
--- 59,68 ----
  The Emacs issue tracker at https://debbugs.gnu.org lets you view bug
  reports and search the database for bugs matching several criteria.
  Messages posted to the bug-gnu-emacs@gnu.org mailing list, mentioned
! above, are recorded by the tracker with the corresponding
! bugs/issues.  If a message to the bug tracker contains a patch, the
! subject of the message shall contain the string "[PATCH]" in order to
! let the bug tracker tag the bug properly.

  GNU ELPA has a 'debbugs' package that allows accessing the tracker
  database from Emacs.

[-- Attachment #3: Type: text/plain, Size: 107 bytes --]


Hmm, and shall we explain also how to reply to bug tracker messages? It
needs another address but the ML.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: rgm@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 25 Mar 2019 17:29:16 +0100
> 
> Like this?
> 
> 
> [2:text/x-diff Hide]
> 
> *** /tmp/ediffYbcrob	2019-03-25 17:26:15.099153743 +0100
> --- /home/albinus/src/emacs/CONTRIBUTE	2019-03-25 17:25:57.710880544 +0100
> ***************
> *** 59,65 ****
>   The Emacs issue tracker at https://debbugs.gnu.org lets you view bug
>   reports and search the database for bugs matching several criteria.
>   Messages posted to the bug-gnu-emacs@gnu.org mailing list, mentioned
> ! above, are recorded by the tracker with the corresponding bugs/issues.
> 
>   GNU ELPA has a 'debbugs' package that allows accessing the tracker
>   database from Emacs.
> --- 59,68 ----
>   The Emacs issue tracker at https://debbugs.gnu.org lets you view bug
>   reports and search the database for bugs matching several criteria.
>   Messages posted to the bug-gnu-emacs@gnu.org mailing list, mentioned
> ! above, are recorded by the tracker with the corresponding
> ! bugs/issues.  If a message to the bug tracker contains a patch, the
> ! subject of the message shall contain the string "[PATCH]" in order to
> ! let the bug tracker tag the bug properly.

I'd prefer 'please include the string "[PATCH]" ...' to using "shall
contain", but otherwise this is fine, thanks.

> Hmm, and shall we explain also how to reply to bug tracker messages? It
> needs another address but the ML.

Is that a serious problem?  IME, both methods work.

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Mon, Mar 25, 2019 at 6:25 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> I'd prefer 'please include the string "[PATCH]" ...' to using "shall
> contain", but otherwise this is fine, thanks.

Better yet: please start the subject with the string "[PATCH]".

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Michael Albinus]

Tadeus Prastowo <tadeus.prastowo@unitn.it> writes:

>> I'd prefer 'please include the string "[PATCH]" ...' to using "shall
>> contain", but otherwise this is fine, thanks.
>
> Better yet: please start the subject with the string "[PATCH]".

To late, I've just committed. And I don't know whether the subject must
*start* with that string.

> Best regards,
> Tadeus

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd prefer 'please include the string "[PATCH]" ...' to using "shall
> contain", but otherwise this is fine, thanks.

Pushed to master.

Re: [RFE] Migration to gitlab

[Glenn Morris]

Michael Albinus wrote:

>> FYI [PATCH] in the subject is treated the same as "Tags: patch".
>
> Thanks, I didn't know (or I did, and forgot). Maybe it's worth to
> mention this in admin/notes/bugtracker?

Nobody reads the docs, else they would use Tags: patch.
Hence the addition of [PATCH] support years ago.
And nobody pays special attention to reports with patches.
(Obviously I exaggerate.)
https://debbugs.gnu.org/rrd/emacs_tag_5y.png

Yrs grumpily...

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 22.03.2019 20:50, Glenn Morris wrote:

> Nobody reads the docs, else they would use Tags: patch.
> Hence the addition of [PATCH] support years ago.

I think it's a bit unrealistic to expect every bug reporter to read the 
bug-reporting docs first.

That's why we (as programmers and software projects in general) have bug 
reporting interfaces with checklists and dropdown menus for tags, etc.

> And nobody pays special attention to reports with patches.
> (Obviously I exaggerate.)
> https://debbugs.gnu.org/rrd/emacs_tag_5y.png

It is quite possible that, instead, we have areas in Emacs that are not 
well-covered by knowledgeable reviewers.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Fri, 22 Mar 2019 12:52:04 -0400
> 
> FYI [PATCH] in the subject is treated the same as "Tags: patch".

Ah, great.  So we probably want to encourage people to use that (many
are already accustomed, I think).

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 20.03.2019 9:23, Eli Zaretskii wrote:

> Unlike in many other projects, I consider the situation with patch
> review, and more generally with the number of domain experts we have
> on board in Emacs, a disaster.

Personally, I expect a lot more packages to be retired or moved from the 
core into ELPA in the future, perhaps tagged as unmaintained. If we 
don't manage to review all patches, it means Emacs has grown larger than 
the core team can deal with. Tools can alleviate that to some extent (to 
help people stretch wider), but not infinitely.

But that's neither here nor there.

> Recent years saw a lot of change in Emacs infrastructure and
> maintenance procedures -- we moved from CVS to Bazaar to Git, we
> removed some of the obstacles to newcomers, such as ChangeLog files,
> we codified the most important parts of the procedures in CONTRIBUTE,
> etc.  This indeed brought welcome new contributors, but the growth is
> very slow, and the impact on the patch review process and on the
> number of people who are proficient in core parts of the internals is
> still very much minor and inadequate, IMO.  E.g., the backlog in patch
> review and in solving reported issues is still unsatisfactory.

You're mentioning some changes, but the patch review process itself has 
changed very little in the last... how many years?

And speaking of backlogs in patch/bug review, I'm personally unsure how 
many bug reports and patches are out there unattended that relate to the 
files that I maintain. The tagging system is barely adequate, and every 
time I use Debbugs I have to rediscover it (as well as search, with its 
bugs) all over again.

> So personally, I don't think we are ready for another significant
> change in our procedures and infrastructure, not before we give some
> more time to these slow tendencies to develop into significant
> qualitative changes.  People who want those infrastructure changes
> should become more involved, so that we reach the critical mass
> sooner.

People work on what they want to work on. Even if they somehow feel more 
encouraged to contribute, not many people are going to work on arbitrary 
pieces of Emacs, or review random patches.

On the other hand, discussing the possibility of a migration and 
agreeing on some specific goals can encourage people to get more 
familiar with Emacs development workflow, even as they try to improve 
it. Which can increase the pool of contributors as well, by itself.

I think it will be helpful to outline and agree on some rough migration 
plan which can be enacted. With steps and conditions for the "people who 
want" to know what to work on.

For instance, here are the steps that I personally could be happy with:

- We already have EMBA and some people proficient with keeping it 
running. We've even pushed a feature upstream, that one of our long-time 
developers requested. Let's mark this one "done".

- Figure out the timeout problems and make the builds more stable.

- Support "merge requests" submitted to EMBA as an official way to 
submit patches for Emacs, document it in Contribute, etc. Some core 
developments will probably say that they would prefer to conduct reviews 
by email anyway, or via some Emacs-based UI instead of the web UI. 
Collect the requirements, agree on necessary features, test them out 
until people are reasonably happy, adopt. Some integration with Debbugs 
and/or Savannah will also be required, I think.

- Migrate from Debbugs to GitLab Issues. The holy grail for me 
personally. But it'll still require a fair amount of work, similar to 
the previous item (but more). Probably far off to the future. We'll get 
there when we get there.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 21 Apr 2019 02:26:44 +0300
> 
> On 20.03.2019 9:23, Eli Zaretskii wrote:
> 
> > Unlike in many other projects, I consider the situation with patch
> > review, and more generally with the number of domain experts we have
> > on board in Emacs, a disaster.
> 
> Personally, I expect a lot more packages to be retired or moved from the 
> core into ELPA in the future, perhaps tagged as unmaintained.

Large parts of, if not the majority, of the areas where we don't have
active experts are not in packages that can be moved to ELPA.  A lot
of that is in C (and most cannot be recoded in Lisp, even if
performance allowed that) or in core packages central to Emacs.

> > Recent years saw a lot of change in Emacs infrastructure and
> > maintenance procedures -- we moved from CVS to Bazaar to Git, we
> > removed some of the obstacles to newcomers, such as ChangeLog files,
> > we codified the most important parts of the procedures in CONTRIBUTE,
> > etc.  This indeed brought welcome new contributors, but the growth is
> > very slow, and the impact on the patch review process and on the
> > number of people who are proficient in core parts of the internals is
> > still very much minor and inadequate, IMO.  E.g., the backlog in patch
> > review and in solving reported issues is still unsatisfactory.
> 
> You're mentioning some changes, but the patch review process itself has 
> changed very little in the last... how many years?

The patch review process should reflect the preferences of the bulk of
those who do the review.  It is IMO wrong and even unfair to force
significant changes in the procedures due to requests from people who
aren't involved enough, because (a) they don't have the right
perspective, and (b) because they won't be there to sustain the
consequences.

> And speaking of backlogs in patch/bug review, I'm personally unsure how 
> many bug reports and patches are out there unattended that relate to the 
> files that I maintain. The tagging system is barely adequate, and every 
> time I use Debbugs I have to rediscover it (as well as search, with its 
> bugs) all over again.

Are you using the debbugs package from ELPA?  If not, I suggest giving
it a try.

> > People who want those infrastructure changes should become more
> > involved, so that we reach the critical mass sooner.
> 
> People work on what they want to work on. Even if they somehow feel more 
> encouraged to contribute, not many people are going to work on arbitrary 
> pieces of Emacs, or review random patches.
> 
> On the other hand, discussing the possibility of a migration and 
> agreeing on some specific goals can encourage people to get more 
> familiar with Emacs development workflow, even as they try to improve 
> it. Which can increase the pool of contributors as well, by itself.

It is a bootstrap-like process, sure.  My point was that we cannot
speed it up beyond some limit, determined by balanced progress in
these two prongs.  I guess you are agreeing with that?

> I think it will be helpful to outline and agree on some rough migration 
> plan which can be enacted. With steps and conditions for the "people who 
> want" to know what to work on.

We could discuss that, but it's IME futile to talk about the parts
that are too far in the future, because when we get to that, both the
people involved and the technologies will change.  So talking about
those distant parts just facilitates long discussions with no
conclusions.  We have past discussions to serve as examples.

Re: [RFE] Migration to gitlab

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> And speaking of backlogs in patch/bug review, I'm personally unsure how
>> many bug reports and patches are out there unattended that relate to the
>> files that I maintain. The tagging system is barely adequate, and every
>> time I use Debbugs I have to rediscover it (as well as search, with its
>> bugs) all over again.
>
> Are you using the debbugs package from ELPA?  If not, I suggest giving
> it a try.

For example, I use heavily the local tagging feature of the debbugs
package. With this, I can always check the status of bug reports I'm
interested in, within seconds and w/o asking myself how to do this.

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 21.04.2019 10:58, Michael Albinus wrote:
> For example, I use heavily the local tagging feature of the debbugs
> package.

Local? Meaning nobody else would see them? At the very least, that means 
I'd need to have the means to find all bug reports relevant to myself.

Whereas in many other projects some person can do bug triage and assign 
them to someone else who is responsible for the given area.

At the moment all I can really do is search for 'ruby' (and other 
relevant package names), which doesn't necessarily include all bug 
reports I could handle. And the search is frickin slow.

> With this, I can always check the status of bug reports I'm
> interested in, within seconds and w/o asking myself how to do this.

It's good we've found certain ways to cope, of course. Emacs might have 
been different otherwise.

Re: [RFE] Migration to gitlab

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

Hi Dmitry,

>> For example, I use heavily the local tagging feature of the debbugs
>> package.
>
> Local? Meaning nobody else would see them?

Yes. It is intended to be a TODO list. When I call debbugs-gnu, I choose
the pseudo-severity "tagged", and I get my list. In any bug list, you
can toggle this local tag by "t".

> At the very least, that means I'd need to have the means to find all
> bug reports relevant to myself.
>
> Whereas in many other projects some person can do bug triage and
> assign them to someone else who is responsible for the given area.

In debbugs, there is the attribute "owner" you can set and
filter. However, it isn't used in the Emacs bug handling. But nobody
prevents you to use that attribute for bugs you declare your
reponsibility.

> At the moment all I can really do is search for 'ruby' (and other
> relevant package names), which doesn't necessarily include all bug
> reports I could handle. And the search is frickin slow.

There is also debbugs-gnu-search, which applies a full text search. See
the manual, (info "(debbugs-ug)")

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 21.04.2019 8:43, Eli Zaretskii wrote:

> Large parts of, if not the majority, of the areas where we don't have
> active experts are not in packages that can be moved to ELPA.  A lot
> of that is in C (and most cannot be recoded in Lisp, even if
> performance allowed that) or in core packages central to Emacs.

Some features will stagnate, some we'll have to cut out in the long run. 
That is probably inevitable as well. The most essential ones will find 
their contributors.

> The patch review process should reflect the preferences of the bulk of
> those who do the review.  It is IMO wrong and even unfair to force
> significant changes in the procedures due to requests from people who
> aren't involved enough, because (a) they don't have the right
> perspective, and (b) because they won't be there to sustain the
> consequences.

Like I said, you have the authority to strongly request the transition 
to be as smooth as possible, so that the important aspects of the 
existing workflow are retained. It's not like you actually love every 
minor detail of how we do review these days that you couldn't bear to 
part even with one of them, is it?

> Are you using the debbugs package from ELPA?  If not, I suggest giving
> it a try.

I've been around for a while, of course I have it installed. Since I 
don't have SMTP configured in Emacs anymore, though, it's become less 
useful. It cannot paper over all deficiencies of the underlying platform 
either. But it's good that we have it, of course.

>> On the other hand, discussing the possibility of a migration and
>> agreeing on some specific goals can encourage people to get more
>> familiar with Emacs development workflow, even as they try to improve
>> it. Which can increase the pool of contributors as well, by itself.
> 
> It is a bootstrap-like process, sure.  My point was that we cannot
> speed it up beyond some limit, determined by balanced progress in
> these two prongs.  I guess you are agreeing with that?

Not really. I don't really understand the idea of "reaching critical 
mass" in this discussion. When would you consider the "mass" to be 
"critical"? When somebody offers to take over as the maintainer? (I'm 
hoping for a "no" here).

I'm saying it's better to encourage the possible contributors to bring 
their own enthusiasm and expertise, even for a while. Not every 
unfinished project is a loss. Someone else can come along and continue 
it. In this case, I would expect a very wide range of people to want to 
see Emacs migrate to GitLab (or one of the competing platforms maybe; 
but mostly GitLab).

And that doesn't mean you'd have to settle for a completely alien new 
workflow that you would be uncomfortable with. Even when we discussed 
bringing over GitLab as a code review platform the previous time, we 
talked about existing Emacs packages that provide access to the features 
of the platform, as well as writing our own if the existing ones turn 
out to be inadequate. That's still feasible.

> We could discuss that, but it's IME futile to talk about the parts
> that are too far in the future, because when we get to that, both the
> people involved and the technologies will change.  So talking about
> those distant parts just facilitates long discussions with no
> conclusions.  We have past discussions to serve as examples.

The past discussion on a similar subject was relatively different, in 
that none of the people involved had both the interest, enough free time 
and expertise to see the project through.

This time we already have a GitLab installation, as well as a few people 
willing to work on integrating it with the larger infrastructure and our 
workflow requirements. An employee of GitLab among them, which likely 
means easier access to upstreaming certain features we'd need to make 
this happen. It's a pretty sweet situation for us not to take an 
advantage of, in my opinion.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 25 Apr 2019 04:06:28 +0300
> 
> On 21.04.2019 8:43, Eli Zaretskii wrote:
> 
> > Large parts of, if not the majority, of the areas where we don't have
> > active experts are not in packages that can be moved to ELPA.  A lot
> > of that is in C (and most cannot be recoded in Lisp, even if
> > performance allowed that) or in core packages central to Emacs.
> 
> Some features will stagnate, some we'll have to cut out in the long run. 

This loses context and perspective.  The context was patch review, not
development.  If someone submits a patch that touches on one of those
areas, do you propose to tell them to drop the patch because no one
really understands its implications?  I doubt that.  The person who
submits the patch might just be that future expert, and we don't want
to scare them away.  So we must review the patch as best as we can,
and that takes an inordinate amount of time and effort.

> > The patch review process should reflect the preferences of the bulk of
> > those who do the review.  It is IMO wrong and even unfair to force
> > significant changes in the procedures due to requests from people who
> > aren't involved enough, because (a) they don't have the right
> > perspective, and (b) because they won't be there to sustain the
> > consequences.
> 
> Like I said, you have the authority to strongly request the transition 
> to be as smooth as possible, so that the important aspects of the 
> existing workflow are retained. It's not like you actually love every 
> minor detail of how we do review these days that you couldn't bear to 
> part even with one of them, is it?

My authority, whether real or imaginary, aside, it's not just me and
my habits.  There are others involved, and by looking at how they
format their messages and how they find related issues, I can guess
that they, too, have efficient workflows in place that will have to be
considered.

I hope my other message could be a good starting point for figuring
out what exactly will constitute a smooth transition, and what are the
necessary conditions for such a transition.

> > It is a bootstrap-like process, sure.  My point was that we cannot
> > speed it up beyond some limit, determined by balanced progress in
> > these two prongs.  I guess you are agreeing with that?
> 
> Not really. I don't really understand the idea of "reaching critical 
> mass" in this discussion. When would you consider the "mass" to be 
> "critical"?

When close to 80% of bugs and patches posted to the issue tracker will
wait less than a week before they get responded in some meaningful way
(excluding a mere acknowledge of seeing the report), and not
necessarily by yours truly.  Sounds good?

> When somebody offers to take over as the maintainer? (I'm 
> hoping for a "no" here).

Feel free to do that as well, it will make me a happier person.

> I'm saying it's better to encourage the possible contributors to bring 
> their own enthusiasm and expertise, even for a while.

Better than what?

And anyway, the issue at hand is not a general one: we all agree that
contributors should be encouraged.  The issue is what to do in
practice to encourage them, and the specific part of that discussed
here is significant changes in the workflow.  It is unclear to me what
practical criteria you are proposing for this trade-off.  It's not an
easy decision, and just the desire to encourage is not enough.

> Not every unfinished project is a loss. Someone else can come along
> and continue it.

Examples from Emacs?  I'm not aware of any, but maybe I missed some.

> In this case, I would expect a very wide range of
> people to want to see Emacs migrate to GitLab (or one of the
> competing platforms maybe; but mostly GitLab).

I'm not sure we understand the practical aspects and consequences of
this.  At least I don't.  Let's see what comes out of the list of
issues I posted in my other message.  I'm especially interested in
hearing opinions of other active developers.

> This time we already have a GitLab installation, as well as a few people 
> willing to work on integrating it with the larger infrastructure and our 
> workflow requirements. An employee of GitLab among them, which likely 
> means easier access to upstreaming certain features we'd need to make 
> this happen. It's a pretty sweet situation for us not to take an 
> advantage of, in my opinion.

I certainly hope so.  But still, IMO we should discuss steps we intend
to be able to take soon, not something for the distant future.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 25.04.2019 12:22, Eli Zaretskii wrote:

>> Some features will stagnate, some we'll have to cut out in the long run.
> 
> This loses context and perspective.  The context was patch review, not
> development.  If someone submits a patch that touches on one of those
> areas, do you propose to tell them to drop the patch because no one
> really understands its implications?  I doubt that.  The person who
> submits the patch might just be that future expert, and we don't want
> to scare them away.  So we must review the patch as best as we can,
> and that takes an inordinate amount of time and effort.

True. In the past, I have reviewed patches in the areas I knew little 
about. The process mostly consists of asking lots of silly questions, 
and if the reporter is patient enough, that can get the patch approved, 
and the reporter can indeed become someone who takes care of a 
particular feature.

That's the optimistic side of the coin.

> My authority, whether real or imaginary, aside, it's not just me and
> my habits.  There are others involved, and by looking at how they
> format their messages and how they find related issues, I can guess
> that they, too, have efficient workflows in place that will have to be
> considered.

Sure.

> I hope my other message could be a good starting point for figuring
> out what exactly will constitute a smooth transition, and what are the
> necessary conditions for such a transition.

That is exactly the change in the tone of this discussion I've been 
hoping to enact.

> When close to 80% of bugs and patches posted to the issue tracker will
> wait less than a week before they get responded in some meaningful way
> (excluding a mere acknowledge of seeing the report), and not
> necessarily by yours truly.  Sounds good?

You mean only after that we can consider changing workflows? A lot of 
big, popular projects (and especially those) have huge numbers of 
untriaged bugs because it's simply a function of a project's popularity.

I honestly do not know what improvement is possible with our current 
resources. The only way I know of improving the situation is to try, and 
try, to attract new contributors. And that can happen if we use newer 
tools which increase visibility into our development process, and makes 
it more approachable for a new contributor.

>> When somebody offers to take over as the maintainer? (I'm
>> hoping for a "no" here).
> 
> Feel free to do that as well, it will make me a happier person.

Much as a like my opinion being heeded, and even the lack of expertise 
aside, it's simply not possible for me to rival the amount of effort you 
are putting into the project. Not in the next several years anyway.

So I'm really thankful you are doing that, even if I don't agree with 
some decisions. Hope you know that.

>> Not every unfinished project is a loss. Someone else can come along
>> and continue it.
> 
> Examples from Emacs?  I'm not aware of any, but maybe I missed some.

Well, not sure what examples you're expecting, but I've picked up some 
features that others started work on (ruby-mode, xref, project.el). And 
the work on the NS port, for instance, has moved between maintainers 
several times on my memory.

>> In this case, I would expect a very wide range of
>> people to want to see Emacs migrate to GitLab (or one of the
>> competing platforms maybe; but mostly GitLab).
> 
> I'm not sure we understand the practical aspects and consequences of
> this.  At least I don't.  Let's see what comes out of the list of
> issues I posted in my other message.  I'm especially interested in
> hearing opinions of other active developers.

Let's!

>> This time we already have a GitLab installation, as well as a few people
>> willing to work on integrating it with the larger infrastructure and our
>> workflow requirements. An employee of GitLab among them, which likely
>> means easier access to upstreaming certain features we'd need to make
>> this happen. It's a pretty sweet situation for us not to take an
>> advantage of, in my opinion.
> 
> I certainly hope so.  But still, IMO we should discuss steps we intend
> to be able to take soon, not something for the distant future.

If you look back at the list I wrote, only the step of Migration off 
Debbugs (the last one) should be considered distant.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 25 Apr 2019 13:35:01 +0300
> 
> > When close to 80% of bugs and patches posted to the issue tracker will
> > wait less than a week before they get responded in some meaningful way
> > (excluding a mere acknowledge of seeing the report), and not
> > necessarily by yours truly.  Sounds good?
> 
> You mean only after that we can consider changing workflows?

That's the criterion I propose, yes.

> A lot of big, popular projects (and especially those) have huge
> numbers of untriaged bugs because it's simply a function of a
> project's popularity.

I see no reason not to triage the bugs quickly, even if a large
portion of the bugs gets triaged into the "unassigned" category.
Triage is not a complex process.

> I honestly do not know what improvement is possible with our current 
> resources. The only way I know of improving the situation is to try, and 
> try, to attract new contributors. And that can happen if we use newer 
> tools which increase visibility into our development process, and makes 
> it more approachable for a new contributor.

The situation actually improves quite steadily.  Just slowly.

> If you look back at the list I wrote, only the step of Migration off 
> Debbugs (the last one) should be considered distant.

So you propose that we use debbugs and Gitlab concurrently?  How's
that supposed to work?

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 25.04.2019 13:55, Eli Zaretskii wrote:

>>> When close to 80% of bugs and patches posted to the issue tracker will
>>> wait less than a week before they get responded in some meaningful way
>>> (excluding a mere acknowledge of seeing the report), and not
>>> necessarily by yours truly.  Sounds good?
>>
>> You mean only after that we can consider changing workflows?
> 
> That's the criterion I propose, yes.

I don't understand. Either you're saying that we simply wait and carry 
on our workflows in exactly the same way until the aforementioned 80% 
happens. Which is a perspective I'm not particularly hopeful about.

OR

We discuss the options, and we're open to making some changes (minor or 
major), as long as we agree that they are for the common good. We can 
also test-drive any new changes in advance before committing to them.

I might be misunderstanding your use of the word "criterion", though.

>> A lot of big, popular projects (and especially those) have huge
>> numbers of untriaged bugs because it's simply a function of a
>> project's popularity.
> 
> I see no reason not to triage the bugs quickly, even if a large
> portion of the bugs gets triaged into the "unassigned" category.
> Triage is not a complex process.

It's a relatively simple, but repetitive process that requires 
interacting with the bug tracker on every step. Which is basically 
impossible to do when one severely dislikes the current bug tracker.

Debbugs aside, not every project has "try to reproduce" as one of the 
steps in bug triage. The bigger ones don't AFAIK. And trying to do that 
would be more time-consuming, as well as require one to familiarize 
themselves with features of Emacs they have no experience/interest in.

On the other hand, the current triage notes mention no categorization 
step, or assignment to responsible parties. Which would be helpful in 
its own right.

Third, since admin/notes/bug-triage is inside admin/, we apparently do 
not expect drive-by contributors in participate in the triage process. 
Even though the steps are relatively simple, and one does not have to 
possess much in-depth knowledge to perform it.

Finally, in my own projects which are fairly mature, I sometimes fail to 
respond to bug reports. The users themselves find existing bug reports 
and comment to confirm that yes, the bug still exists and remains a 
problem. Triage success! That also works to confirm that a bug should be 
made a priority (old report, users still commenting on it).

I remember certain people on this mailing list complaining about 
duplicates in the bug tracker (and users failing to do the search). 
Well, get a bug tracker with a user friendlier interface (visibility, 
searchability, etc), and the users will do more work for you.

>> I honestly do not know what improvement is possible with our current
>> resources. The only way I know of improving the situation is to try, and
>> try, to attract new contributors. And that can happen if we use newer
>> tools which increase visibility into our development process, and makes
>> it more approachable for a new contributor.
> 
> The situation actually improves quite steadily.  Just slowly.

The improvement is to be expected, given your more conservative approach 
to Emacs development than the previous maintainer did. But it's no 
guarantee that the ratio is ever going to reach 100%, or even 80%, and 
stay there.

>> If you look back at the list I wrote, only the step of Migration off
>> Debbugs (the last one) should be considered distant.
> 
> So you propose that we use debbugs and Gitlab concurrently?  How's
> that supposed to work?

I think we have a sub-thread in this discussion that's better suited for 
this question.

But in short, bug reports to in Debbugs, patch submissions to into 
GitLab (and also Debbugs sometimes, though we could automate some 
process to move them over to GitLab from there). I'm hoping this can be 
a step to easy the transition to using GitLab full-time, but it can 
continue for a while (and never end, basically).

During that time you would evaluate how easy it is to review patches in 
GitLab (maybe using some Emacs-based client, maybe over email), as well 
as simply leave comments there.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 25 Apr 2019 18:01:19 +0300
> 
> On 25.04.2019 13:55, Eli Zaretskii wrote:
> 
> >>> When close to 80% of bugs and patches posted to the issue tracker will
> >>> wait less than a week before they get responded in some meaningful way
> >>> (excluding a mere acknowledge of seeing the report), and not
> >>> necessarily by yours truly.  Sounds good?
> >>
> >> You mean only after that we can consider changing workflows?
> > 
> > That's the criterion I propose, yes.
> 
> I don't understand. Either you're saying that we simply wait and carry 
> on our workflows in exactly the same way until the aforementioned 80% 
> happens.

Not "exactly the same", but without "significant changes", yes.

> Which is a perspective I'm not particularly hopeful about.

Why?  You think it's a tough criterion to meet?  I actually think the
bar is quite low.  How many new bugs get reported each day?  2? 5?
How hard is it to triage 80% of that, even given the relatively small
number of people who currently do that?

> > I see no reason not to triage the bugs quickly, even if a large
> > portion of the bugs gets triaged into the "unassigned" category.
> > Triage is not a complex process.
> 
> It's a relatively simple, but repetitive process that requires 
> interacting with the bug tracker on every step.

Does it?  The bugs get mailed to you if you subscribe, so no
interaction is needed, until you send a short email after you finish
the triage.  I only ever need to interact with the tracker when
looking up an old bug report, or searching for related issues.  The
initial handling of a new bug almost never needs any interaction.

> Debbugs aside, not every project has "try to reproduce" as one of the 
> steps in bug triage.

It isn't a requirement.  If you are able to triage or fix without
reproducing, no one will object.

> And trying to do that would be more time-consuming, as well as
> require one to familiarize themselves with features of Emacs they
> have no experience/interest in.

It's harder, yes.  But that's the job, and it must be done.  And it
becomes easier with time, as you become familiar with more and more
areas.

> On the other hand, the current triage notes mention no categorization 
> step

What do you mean by categorization?  It does include determining the
priority.

> or assignment to responsible parties.

It does, AFAICT:

  5. Who should be the owner?

> Third, since admin/notes/bug-triage is inside admin/, we apparently do 
> not expect drive-by contributors in participate in the triage process. 

No, we don't.  But no one will object to them doing so.  No one needs
a permission to start responding to bug reports, everybody is welcome.

> Finally, in my own projects which are fairly mature, I sometimes fail to 
> respond to bug reports. The users themselves find existing bug reports 
> and comment to confirm that yes, the bug still exists and remains a 
> problem. Triage success!

We have this on the bug list as well: people confirm that they see a
problem reported by someone else.  But that's just the beginning of a
triage, it just means the bug is not "not reproducible".

> That also works to confirm that a bug should be made a priority (old
> report, users still commenting on it).

Not necessarily.  Priority of a bug doesn't necessarily become higher
with time, it could actually become low in some cases (people manage
to get by).

> I remember certain people on this mailing list complaining about 
> duplicates in the bug tracker (and users failing to do the search). 
> Well, get a bug tracker with a user friendlier interface (visibility, 
> searchability, etc), and the users will do more work for you.

All else being equal, sure.  But there isn't such a beast, TANSTAAFL.

And I'm not really sure searching debbugs is such a black art.
perhaps Noam and Glenn could share their experience and methods, and
we will all become better searchers.

> >> I honestly do not know what improvement is possible with our current
> >> resources. The only way I know of improving the situation is to try, and
> >> try, to attract new contributors. And that can happen if we use newer
> >> tools which increase visibility into our development process, and makes
> >> it more approachable for a new contributor.
> > 
> > The situation actually improves quite steadily.  Just slowly.
> 
> The improvement is to be expected, given your more conservative approach 
> to Emacs development than the previous maintainer did.

I'm talking about the situation with bug triage and patch review.
Whatever my approach is, it cannot affect those, that's entirely up to
the people who volunteer their time for doing that.  I'm glad that the
situation with this is slowly improving.

> But in short, bug reports to in Debbugs, patch submissions to into 
> GitLab (and also Debbugs sometimes, though we could automate some 
> process to move them over to GitLab from there).

So we are supposed to have 2 sites/UIs open when dealing with a bug
report to which someone suggested a solution?  Is that an improvement?

> During that time you would evaluate how easy it is to review patches in 
> GitLab (maybe using some Emacs-based client, maybe over email), as well 
> as simply leave comments there.

Please read my notes about the main issues I see with Gitlab:
efficient handling of bugs for which there's no patch yet is much more
important than efficient review of patches, primarily because we have
much more bug reports than patches on any given day.  A solution that
makes patch review easier, but does nothing to improve bug handling is
unlikely to get my vote, because I think this is backwards: we should
be solving the most important bottlenecks first.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 25.04.2019 22:54, Eli Zaretskii wrote:

> Not "exactly the same", but without "significant changes", yes.

I see. Probably. (We could discuss the meaning of "significant", but 
let's not).

>> Which is a perspective I'm not particularly hopeful about.
> 
> Why?  You think it's a tough criterion to meet?  I actually think the
> bar is quite low.  How many new bugs get reported each day?  2? 5?
> How hard is it to triage 80% of that, even given the relatively small
> number of people who currently do that?

(I hope we're not talking about my own participation, with the backlog I 
already have, and, well, Debbugs still being there).

On the one hand, you're probably right. On the other, there must be a 
reason it still hasn't happened yet.

>> It's a relatively simple, but repetitive process that requires
>> interacting with the bug tracker on every step.
> 
> Does it?  The bugs get mailed to you if you subscribe, so no
> interaction is needed, until you send a short email after you finish
> the triage.  I only ever need to interact with the tracker when
> looking up an old bug report, or searching for related issues.  The
> initial handling of a new bug almost never needs any interaction.

So, okay, every step but the first (receiving the email?). That changes 
very little. You need to search, tag, Cc somebody else, maybe.

Every one of these actions is noticeably slower here than what I'm used 
to in other projects. More error-prone, too.

>> Debbugs aside, not every project has "try to reproduce" as one of the
>> steps in bug triage.
> 
> It isn't a requirement.  If you are able to triage or fix without
> reproducing, no one will object.

"Manage". I mean that not trying to reproduce is the norm: the 
volunteers look for similar bug reports, categorize them and forward to 
relevant teams.

> It's harder, yes.  But that's the job, and it must be done.  And it
> becomes easier with time, as you become familiar with more and more
> areas.

To be honest: that's only an enticing prospect if I'm aiming to be an 
Emacs maintainer. There's not enough free space in my head already.

>> On the other hand, the current triage notes mention no categorization
>> step
> 
> What do you mean by categorization?  It does include determining the
> priority.

I rather meant assigning to an appropriate subsystem or subpackage (then 
someone responsible for it can take over).

>> or assignment to responsible parties.
> 
> It does, AFAICT:
> 
>    5. Who should be the owner?

OK. But to be pedantic, the document only tells me to ask the question, 
but not what to do with the result. And there's no "owner" field in Debbugs.

I'd have to search some files inside the Emacs repo (which could be 
outdated or don't have the full info), Cc somebody if I find them, and 
write a full, grammatically correct sentence (or more) to bring it to 
the owner's attention.

>> Third, since admin/notes/bug-triage is inside admin/, we apparently do
>> not expect drive-by contributors in participate in the triage process.
> 
> No, we don't.  But no one will object to them doing so.  No one needs
> a permission to start responding to bug reports, everybody is welcome.

I'm saying you might want to move that information somewhere else. 
CONTRIBUTE is already long, though. So I don't have a better proposal 
for the *current* workflow.

>> Finally, in my own projects which are fairly mature, I sometimes fail to
>> respond to bug reports. The users themselves find existing bug reports
>> and comment to confirm that yes, the bug still exists and remains a
>> problem. Triage success!
> 
> We have this on the bug list as well: people confirm that they see a
> problem reported by someone else.

It is, of course, just my experience: but I see that a lot more often in 
the GitHub bug tracker than over here in Debbugs. An order of magnitude 
more often.

>> That also works to confirm that a bug should be made a priority (old
>> report, users still commenting on it).
> 
> Not necessarily.  Priority of a bug doesn't necessarily become higher
> with time, it could actually become low in some cases (people manage
> to get by).

It works to confirm the priority when new users keep commenting on old 
bug reports.

>> I remember certain people on this mailing list complaining about
>> duplicates in the bug tracker (and users failing to do the search).
>> Well, get a bug tracker with a user friendlier interface (visibility,
>> searchability, etc), and the users will do more work for you.
> 
> All else being equal, sure.  But there isn't such a beast, TANSTAAFL.

Indeed, we can't just get a "better Debbugs". Someone would have to 
sacrifice something, at least a little.

We might get close enough, though.

> And I'm not really sure searching debbugs is such a black art.
> perhaps Noam and Glenn could share their experience and methods, and
> we will all become better searchers.

That's not the point. I know how to search Debbugs (it's annoying and 
slow, but I get the results). A lot of our users do not.

> I'm talking about the situation with bug triage and patch review.
> Whatever my approach is, it cannot affect those, that's entirely up to
> the people who volunteer their time for doing that.  I'm glad that the
> situation with this is slowly improving.

I'm glad that's happening, then.

>> But in short, bug reports to in Debbugs, patch submissions to into
>> GitLab (and also Debbugs sometimes, though we could automate some
>> process to move them over to GitLab from there).
> 
> So we are supposed to have 2 sites/UIs open when dealing with a bug
> report to which someone suggested a solution?  Is that an improvement?

We would have a separate dedicated place and workflow for handling code 
reviews. Stefan seemed enthusiastic enough about "a system where we can
receive contributions via merge requests". The exact improvement would 
depend on how well the reviewers would be able to take advantage of 
GitHub's features (the web UI has a lot of them; whatever interface we 
choose would either have to simplify or reimplement some of them).

That is, improvement from your side. The users who don't mind using the 
web interface will likely benefit the most. And we'll likely see more 
user attention as a result.

> Please read my notes about the main issues I see with Gitlab:

I've seen it, and I'll let Toon answer first. Let's not spread that 
detailed discussion over many subthreads.

> efficient handling of bugs for which there's no patch yet is much more
> important than efficient review of patches, primarily because we have
> much more bug reports than patches on any given day.  A solution that
> makes patch review easier, but does nothing to improve bug handling is
> unlikely to get my vote, because I think this is backwards: we should
> be solving the most important bottlenecks first.

Bug handling is "easier" than doing code reviews in a lot of respects. 
First and foremost, email notifications and responding to reports via 
email should already work. There are definite advantages to be gained 
from migrating the bug tracker to GitLab, but we need some trial period, 
and probably don't want to deal with two bug trackers at once.

Adding Merge Requests to our workflow first would force us to work out 
the kinks in the more difficult parts of the integration, as well as 
test drive also the same features that bug reports have (commenting 
through email, searching, tagging, changing status, etc).

Re: [RFE] Migration to gitlab

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> And there's no "owner" field in Debbugs.

There is.

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 26.04.2019 10:52, Michael Albinus wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> And there's no "owner" field in Debbugs.
> 
> There is.

Interesting. Could you show a bug report with assigned owner? Do they 
get Cc'd with every message, etc?

Re: [RFE] Migration to gitlab

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>> And there's no "owner" field in Debbugs.
>>
>> There is.
>
> Interesting. Could you show a bug report with assigned owner? Do they
> get Cc'd with every message, etc?

It's rarely used. Bug#6850 is owned by me, for example. I don't remember
whether an owner is Cc'ed with every message. But these email
notifications aren't satisfactory yet in debbugs at all, there are bug
reports about waiting for improvement.

And likely, the original debbugs software from Debian is better with
this meanwhile; we need to synchronize our fork. This is a pending task,
yes.

Best regards, Michael.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 26 Apr 2019 02:16:34 +0300
> 
> > Why?  You think it's a tough criterion to meet?  I actually think the
> > bar is quite low.  How many new bugs get reported each day?  2? 5?
> > How hard is it to triage 80% of that, even given the relatively small
> > number of people who currently do that?
> 
> (I hope we're not talking about my own participation, with the backlog I 
> already have, and, well, Debbugs still being there).
> 
> On the one hand, you're probably right. On the other, there must be a 
> reason it still hasn't happened yet.

Maybe people are not aware how close we are to that goal.  Or maybe
they didn't try to go out of the area of their immediate expertise for
fear of something that shouldn't frighten them.

> >> It's a relatively simple, but repetitive process that requires
> >> interacting with the bug tracker on every step.
> > 
> > Does it?  The bugs get mailed to you if you subscribe, so no
> > interaction is needed, until you send a short email after you finish
> > the triage.  I only ever need to interact with the tracker when
> > looking up an old bug report, or searching for related issues.  The
> > initial handling of a new bug almost never needs any interaction.
> 
> So, okay, every step but the first (receiving the email?).

No, all of the steps.  Even the result of the triage is an email
message.  And the triage itself has nothing to do with the tracker, it
requires understanding the report, some knowledge of Emacs, and common
sense.  It can also include asking the OP some clarifying questions.

> Every one of these actions is noticeably slower here than what I'm used 
> to in other projects. More error-prone, too.

<Shrug> I don't understand why.  It's mostly writing text, which
should be the same speed everywhere.

> >> Debbugs aside, not every project has "try to reproduce" as one of the
> >> steps in bug triage.
> > 
> > It isn't a requirement.  If you are able to triage or fix without
> > reproducing, no one will object.
> 
> "Manage". I mean that not trying to reproduce is the norm: the 
> volunteers look for similar bug reports, categorize them and forward to 
> relevant teams.

I fail to see how this would be useful.

> >> On the other hand, the current triage notes mention no categorization
> >> step
> > 
> > What do you mean by categorization?  It does include determining the
> > priority.
> 
> I rather meant assigning to an appropriate subsystem or subpackage

That's usually a very large portion of figuring out the reason for the
bug.  Someone who got that far should just go on and describe the
reasons themselves.

> >> or assignment to responsible parties.
> > 
> > It does, AFAICT:
> > 
> >    5. Who should be the owner?
> 
> OK. But to be pedantic, the document only tells me to ask the question, 
> but not what to do with the result. And there's no "owner" field in Debbugs.

The text is not cast in stone, it can be clarified.  (Though to me,
what to do is obvious, not to be pedantic.)

> I'd have to search some files inside the Emacs repo (which could be 
> outdated or don't have the full info), Cc somebody if I find them, and 
> write a full, grammatically correct sentence (or more) to bring it to 
> the owner's attention.

Any bug tracker will require all of that, with the possible exception
of the last part.  And at least for me, a sentence or two explaining
why you think the bug is in my backyard is much better than just a
message "assigned to you" with no explanation whatsoever.  YMMV, of
course.

> >> Third, since admin/notes/bug-triage is inside admin/, we apparently do
> >> not expect drive-by contributors in participate in the triage process.
> > 
> > No, we don't.  But no one will object to them doing so.  No one needs
> > a permission to start responding to bug reports, everybody is welcome.
> 
> I'm saying you might want to move that information somewhere else. 
> CONTRIBUTE is already long, though. So I don't have a better proposal 
> for the *current* workflow.

CONTRIBUTE already encourages to look at and help dealing with bug
reports.

> >> Finally, in my own projects which are fairly mature, I sometimes fail to
> >> respond to bug reports. The users themselves find existing bug reports
> >> and comment to confirm that yes, the bug still exists and remains a
> >> problem. Triage success!
> > 
> > We have this on the bug list as well: people confirm that they see a
> > problem reported by someone else.
> 
> It is, of course, just my experience: but I see that a lot more often in 
> the GitHub bug tracker than over here in Debbugs. An order of magnitude 
> more often.

Not sure why this is important: IME, such messages are in many cases
of little help in investigating the issue and finding its causes.

> >> I remember certain people on this mailing list complaining about
> >> duplicates in the bug tracker (and users failing to do the search).
> >> Well, get a bug tracker with a user friendlier interface (visibility,
> >> searchability, etc), and the users will do more work for you.
> > 
> > All else being equal, sure.  But there isn't such a beast, TANSTAAFL.
> 
> Indeed, we can't just get a "better Debbugs". Someone would have to 
> sacrifice something, at least a little.

More importantly, you get fed features and issues you never asked for,
that you need to decide whether you want in the first place.

> > And I'm not really sure searching debbugs is such a black art.
> > perhaps Noam and Glenn could share their experience and methods, and
> > we will all become better searchers.
> 
> That's not the point. I know how to search Debbugs (it's annoying and 
> slow, but I get the results). A lot of our users do not.

If the advice is readily available and discoverable, it might help
others.

> >> But in short, bug reports to in Debbugs, patch submissions to into
> >> GitLab (and also Debbugs sometimes, though we could automate some
> >> process to move them over to GitLab from there).
> > 
> > So we are supposed to have 2 sites/UIs open when dealing with a bug
> > report to which someone suggested a solution?  Is that an improvement?
> 
> We would have a separate dedicated place and workflow for handling code 
> reviews.

That's not how issue-tracking systems I'm familiar with work.  They
let you have a single locus where the issue is described, discussed,
suggested patches are linked to, and the changeset(s) committed to
resolve can be easily called up and reviewed.  Separate place for
patch review sounds like a step back to me, as currently we have them
in the same place as the bug reports.

> Stefan seemed enthusiastic enough about "a system where we can
> receive contributions via merge requests". The exact improvement would 
> depend on how well the reviewers would be able to take advantage of 
> GitHub's features (the web UI has a lot of them; whatever interface we 
> choose would either have to simplify or reimplement some of them).
> 
> That is, improvement from your side. The users who don't mind using the 
> web interface will likely benefit the most. And we'll likely see more 
> user attention as a result.
> 
> > Please read my notes about the main issues I see with Gitlab:
> 
> I've seen it, and I'll let Toon answer first. Let's not spread that 
> detailed discussion over many subthreads.

So I won't respond to above comments about merge requests, because
that's exactly the stuff of the other subthread.

> Bug handling is "easier" than doing code reviews in a lot of respects. 

IME, it's actually the other way around, assuming that "bug handling"
includes all the way until the bug's root causes are revealed and
understood.

> First and foremost, email notifications and responding to reports via 
> email should already work. There are definite advantages to be gained 
> from migrating the bug tracker to GitLab, but we need some trial period, 
> and probably don't want to deal with two bug trackers at once.
> 
> Adding Merge Requests to our workflow first would force us to work out 
> the kinks in the more difficult parts of the integration, as well as 
> test drive also the same features that bug reports have (commenting 
> through email, searching, tagging, changing status, etc).

This again belongs to the other subthread, not here.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 26.04.2019 11:05, Eli Zaretskii wrote:

> Maybe people are not aware how close we are to that goal.  Or maybe
> they didn't try to go out of the area of their immediate expertise for
> fear of something that shouldn't frighten them.

Repeated calls for help with triage on emacs-devel could do the trick, 
then. Maybe.

>> So, okay, every step but the first (receiving the email?).
> 
> No, all of the steps.  Even the result of the triage is an email
> message.  And the triage itself has nothing to do with the tracker, it
> requires understanding the report, some knowledge of Emacs, and common
> sense.  It can also include asking the OP some clarifying questions.

Again:

- Searching the bug tracker for duplicates.
- Tagging the bug.
- Changing priority.
- Closing it as a duplicate, maybe.

All of these require interacting with Debbugs. Usually through the 
control server.

>> Every one of these actions is noticeably slower here than what I'm used
>> to in other projects. More error-prone, too.
> 
> <Shrug> I don't understand why.  It's mostly writing text, which
> should be the same speed everywhere.

Because most of the time I can just click a button instead of having to 
write an essay.

Or, in the case of search, it's usually more intuitive and, most 
importantly, *faster*.

>> "Manage". I mean that not trying to reproduce is the norm: the
>> volunteers look for similar bug reports, categorize them and forward to
>> relevant teams.
> 
> I fail to see how this would be useful.

It saves time for other people.

For instance, I would be delighted to be able to see the list of bugs 
that someone at some point thought I could take care of best (as, say, 
tagged me as their owner). The ones that are categorized wrongly, I 
could forward to someone else.

>> I rather meant assigning to an appropriate subsystem or subpackage
> 
> That's usually a very large portion of figuring out the reason for the
> bug.  Someone who got that far should just go on and describe the
> reasons themselves.

They don't have to find out the reason with 100% certainty. A lot of the 
time, the general area of responsibility is pretty obvious (Ruby 
support? tag with 'ruby'!)

>> I'd have to search some files inside the Emacs repo (which could be
>> outdated or don't have the full info), Cc somebody if I find them, and
>> write a full, grammatically correct sentence (or more) to bring it to
>> the owner's attention.
> 
> Any bug tracker will require all of that, with the possible exception
> of the last part. 

If there was a pre-defined list of subsystems, bugs could be forwarded 
to those, with the forwarder not having to remember the exact people 
responsible. And then either the bug tracker has the necessary emails 
(and all people in the subgroup get notified), or each individual 
developer could once in a while do a search for tags within their area 
of responsibility. Could be a combination of both.

> And at least for me, a sentence or two explaining
> why you think the bug is in my backyard is much better than just a
> message "assigned to you" with no explanation whatsoever.  YMMV, of
> course.

Sometimes it's very obvious. But if the person doing the triage has 
something meaningful to add to the bug report, then yes, by all means.

I think having all bugs assigned but without a personal message is still 
better than not having all bugs assigned. You could always ask if you 
think they made the wrong choice.

> Not sure why this is important: IME, such messages are in many cases
> of little help in investigating the issue and finding its causes.

Again: knowing that the bug is still reproducible and knowing it still 
bothers people. Is that not useful in your book?

Also, users describe their workarounds, offer their half-baked 
solutions, and even sometimes end up offering patches. This, again, IME 
happens more often in my projects that use the GitHub issue tracker.

>> Indeed, we can't just get a "better Debbugs". Someone would have to
>> sacrifice something, at least a little.
> 
> More importantly, you get fed features and issues you never asked for,
> that you need to decide whether you want in the first place.

Yes, you'll need to decide. Just try to weigh that against other people 
*finally* getting to use said features.

>> That's not the point. I know how to search Debbugs (it's annoying and
>> slow, but I get the results). A lot of our users do not.
> 
> If the advice is readily available and discoverable, it might help
> others.

To really be discoverable it would need to be easy to use from the web 
interface. Like them or not, they are popular, and they're here to stay.

>> We would have a separate dedicated place and workflow for handling code
>> reviews.
> 
> That's not how issue-tracking systems I'm familiar with work.  They
> let you have a single locus where the issue is described, discussed,
> suggested patches are linked to, and the changeset(s) committed to
> resolve can be easily called up and reviewed.  Separate place for
> patch review sounds like a step back to me, as currently we have them
> in the same place as the bug reports.

In short: MR provide the same features as issues, but more. You can 
still lead discussions and post textual patches, but they also include a 
specialized review-and-merge UI.

>> I've seen it, and I'll let Toon answer first. Let's not spread that
>> detailed discussion over many subthreads.
> 
> So I won't respond to above comments about merge requests, because
> that's exactly the stuff of the other subthread.

Do you want to open a new thread for that? At this point we're drowning 
in nested subthreads, and it's not so great to read in my email client.

>> Bug handling is "easier" than doing code reviews in a lot of respects.
> 
> IME, it's actually the other way around, assuming that "bug handling"
> includes all the way until the bug's root causes are revealed and
> understood.

By "easier", I mean technically simpler, in terms of UI features 
involved. So the said features would be easier to re-implement in a 
dedicated Emacs-based client.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 27 Apr 2019 04:40:06 +0300
> Cc: theophilusx@gmail.com, emacs-devel@gnu.org, hi-angel@yandex.ru
> 
> On 26.04.2019 11:05, Eli Zaretskii wrote:
> 
> > Maybe people are not aware how close we are to that goal.  Or maybe
> > they didn't try to go out of the area of their immediate expertise for
> > fear of something that shouldn't frighten them.
> 
> Repeated calls for help with triage on emacs-devel could do the trick, 
> then. Maybe.

Then please consider this one of them.

> > No, all of the steps.  Even the result of the triage is an email
> > message.  And the triage itself has nothing to do with the tracker, it
> > requires understanding the report, some knowledge of Emacs, and common
> > sense.  It can also include asking the OP some clarifying questions.
> 
> Again:
> 
> - Searching the bug tracker for duplicates.

Not required, just a nice bonus.

> - Tagging the bug.
> - Changing priority.
> - Closing it as a duplicate, maybe.

All done in a single step after triage is completed.  (And if the bug
is a duplicate, it should be merged, not closed.)

The main effort in the triage is something entirely unrelated to the
tracker.  It has to do with understanding the report, perhaps
reproducing the issue, and then deciding what is the next step for its
processing.  You somehow exaggerate the importance of interaction with
the bug tracker, and entirely omit the main part of the activity.
That doesn't seem to be a useful way of discussing this.

> >> Every one of these actions is noticeably slower here than what I'm used
> >> to in other projects. More error-prone, too.
> > 
> > <Shrug> I don't understand why.  It's mostly writing text, which
> > should be the same speed everywhere.
> 
> Because most of the time I can just click a button instead of having to 
> write an essay.

"Essay" being those couple of sentences that describe your take of the
issue?  Another exaggeration, I'd say.

Clicking a button loses information, because things you learned during
the triage are not communicated to the next person who will handle
it.  Having the button to click invites people to go the easy way and
lose that information.  It reminds me the GUI of some VCS I used to
use years ago, which allowed people to make a commit with an empty log
message.  Guess how many of them actually wrote a log message.

> Or, in the case of search, it's usually more intuitive and, most 
> importantly, *faster*.

How much time does it take to write a couple of sentences?  And doing
so will in many cases prompt you to have another look at the problem,
perhaps seeing additional, sometimes entirely new aspects of it.  It
is a well-known trivium that explaining something to someone else
causes you to better understand the issue you are describing.  It's a
net win, even though it will use up slightly more of your time.

> >> "Manage". I mean that not trying to reproduce is the norm: the
> >> volunteers look for similar bug reports, categorize them and forward to
> >> relevant teams.
> > 
> > I fail to see how this would be useful.
> 
> It saves time for other people.

Not IME.

> For instance, I would be delighted to be able to see the list of bugs 
> that someone at some point thought I could take care of best (as, say, 
> tagged me as their owner).

This is only relevant for issues created before you took charge.  The
ones created after that arrive to you one by one; how many seconds
does it take for you to understand whether an issue is in your area or
not?

> >> I rather meant assigning to an appropriate subsystem or subpackage
> > 
> > That's usually a very large portion of figuring out the reason for the
> > bug.  Someone who got that far should just go on and describe the
> > reasons themselves.
> 
> They don't have to find out the reason with 100% certainty. A lot of the 
> time, the general area of responsibility is pretty obvious (Ruby 
> support? tag with 'ruby'!)

Your examples are of the kind that is quite rare in Emacs maintenance.
Most of the bug reports are nowhere near being so clearly classified.
Even a problem with Ruby support could be due to something much
deeper, like syntax or font-lock or even regular expressions.  That is
why I said that figuring out the subsystem is a large part of finding
the cause.

It could be that a quick-and-dirty classification of this kind is of
some help, assuming the person who is responsible for Ruby is active
enough to quickly take a look and reassign to someone else if needed.
(But if he/she is active, then why didn't they respond in the first
place?)  However, even under this assumption, what do you do with
reports related to code in simple.el or in faces.el or in frame.el?
Emacs is an old and very stable project, so a large portion of
reported issues are not simple bugs in a recent commit.

> >> I'd have to search some files inside the Emacs repo (which could be
> >> outdated or don't have the full info), Cc somebody if I find them, and
> >> write a full, grammatically correct sentence (or more) to bring it to
> >> the owner's attention.
> > 
> > Any bug tracker will require all of that, with the possible exception
> > of the last part. 
> 
> If there was a pre-defined list of subsystems, bugs could be forwarded 
> to those, with the forwarder not having to remember the exact people 
> responsible. And then either the bug tracker has the necessary emails 
> (and all people in the subgroup get notified), or each individual 
> developer could once in a while do a search for tags within their area 
> of responsibility. Could be a combination of both.

We don't have subgroups.  We do have a kind of ad-hoc subsystem list,
see admin/MAINTAINERS.  CC'ing the relevant person should be good
enough, as we don't have much overlap anyway.

I'd welcome extensions of this and perhaps making debbugs aware of
that, feel free to work on that.  But I think these are very minor
aspects, certainly compared to the larger issues we have now.

> I think having all bugs assigned but without a personal message is still 
> better than not having all bugs assigned.

I don't see how that would be better.  People who are motivated to
work on bugs read the bug list anyway, and people who are less
motivated are known not to respond to direct emails for weeks and
months on end.  We are not an enterprise where a manager can cause
subordinates to get their act together by showing a list of assigned
but unhandled issues, so having a list of many unhandled issues
assigned to someone specific is of no particular importance for
resolving the issues, no better than having a list of unhandled issues
disregarding any assignments.

> > Not sure why this is important: IME, such messages are in many cases
> > of little help in investigating the issue and finding its causes.
> 
> Again: knowing that the bug is still reproducible and knowing it still 
> bothers people. Is that not useful in your book?

Very little, and in some cases not at all.

> Also, users describe their workarounds, offer their half-baked 
> solutions, and even sometimes end up offering patches. This, again, IME 
> happens more often in my projects that use the GitHub issue tracker.

"More often" than what?  And why do you think the frequency of that is
related to the issue tracker being used?  Could it perhaps be related
to the relative complexity of the projects being compared?

> > If the advice is readily available and discoverable, it might help
> > others.
> 
> To really be discoverable it would need to be easy to use from the web 
> interface. Like them or not, they are popular, and they're here to stay.

The entire contents of the Emacs repository is reachable from a
browser, so this is not an issue.

> >> We would have a separate dedicated place and workflow for handling code
> >> reviews.
> > 
> > That's not how issue-tracking systems I'm familiar with work.  They
> > let you have a single locus where the issue is described, discussed,
> > suggested patches are linked to, and the changeset(s) committed to
> > resolve can be easily called up and reviewed.  Separate place for
> > patch review sounds like a step back to me, as currently we have them
> > in the same place as the bug reports.
> 
> In short: MR provide the same features as issues, but more. You can 
> still lead discussions and post textual patches, but they also include a 
> specialized review-and-merge UI.

You've changed the subject.  The specific issue here was that using 2
separate places, one for bugs and another for patches, is a step
backward.  It was your proposal to use 2 separate places.  If you now
say we could do it in one place, then please describe how this will
work with MR being the vehicle.  What would be the workflow, when
there's no patch to start an issue?

> >> I've seen it, and I'll let Toon answer first. Let's not spread that
> >> detailed discussion over many subthreads.
> > 
> > So I won't respond to above comments about merge requests, because
> > that's exactly the stuff of the other subthread.
> 
> Do you want to open a new thread for that?

No need, just respond to that other thread, where I described my main
concerns with the Gitlab proposal.

> At this point we're drowning in nested subthreads

We are?  I see only 2 subthreads: this one, and that other one, where
my message didn't see any responses that discuss my concerns.

> >> Bug handling is "easier" than doing code reviews in a lot of respects.
> > 
> > IME, it's actually the other way around, assuming that "bug handling"
> > includes all the way until the bug's root causes are revealed and
> > understood.
> 
> By "easier", I mean technically simpler, in terms of UI features 
> involved. So the said features would be easier to re-implement in a 
> dedicated Emacs-based client.

If you say so.  My point was that having those features is much more
important than having features that facilitate patch review.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 27.04.2019 12:43, Eli Zaretskii wrote:

>> Repeated calls for help with triage on emacs-devel could do the trick,
>> then. Maybe.
> 
> Then please consider this one of them.

*shrug* I look at the recent reports, and most are far from my 
interests. Lots of ones involving Tramp, Gnus, emailing and eww 
recently. I would know who to forward them to, though.

>> - Searching the bug tracker for duplicates.
> 
> Not required, just a nice bonus.

It could be helpful to save time, or find other bug reports related to 
the subject. We very rarely do that (or at least I) in part because the 
available tools don't make that too easy.

A quick (and maybe automated) search for duplicates would also be of 
help if we start getting more bug reports, which is a "danger" if we 
switch to a more user-accessible bug tracker.

>> - Tagging the bug.
>> - Changing priority.
>> - Closing it as a duplicate, maybe.
> 
> All done in a single step after triage is completed.  (And if the bug
> is a duplicate, it should be merged, not closed.)

One still has to know or remember the syntax.

> The main effort in the triage is something entirely unrelated to the
> tracker.  It has to do with understanding the report, perhaps
> reproducing the issue, and then deciding what is the next step for its
> processing.

It doesn't all have to be done by the same person, however.

> You somehow exaggerate the importance of interaction with
> the bug tracker, and entirely omit the main part of the activity.
> That doesn't seem to be a useful way of discussing this.

You seem to insist that the amount of effort I *could* spend on bugs 
that aren't interesting to me is strictly insufficient. Okay.

>> Because most of the time I can just click a button instead of having to
>> write an essay.
> 
> "Essay" being those couple of sentences that describe your take of the
> issue?  Another exaggeration, I'd say.

Can we call it poetic wording? To get the emotion across. Of how the 
difference often feels.

> Clicking a button loses information, because things you learned during
> the triage are not communicated to the next person who will handle
> it.

Nobody is stopping me/you from adding that information in a comment as well.

But when I just need to reopen a bug, or add a "fixed in" header, or so 
on, there's no extra information to be added.

> Having the button to click invites people to go the easy way and
> lose that information.  It reminds me the GUI of some VCS I used to
> use years ago, which allowed people to make a commit with an empty log
> message.  Guess how many of them actually wrote a log message.

We can still write nonsense in Git logs. But we choose not to.

> How much time does it take to write a couple of sentences?  And doing
> so will in many cases prompt you to have another look at the problem,
> perhaps seeing additional, sometimes entirely new aspects of it.  It
> is a well-known trivium that explaining something to someone else
> causes you to better understand the issue you are describing.  It's a
> net win, even though it will use up slightly more of your time.

Or I could use the saved time and brain energy to work on a new feature.

>>>> "Manage". I mean that not trying to reproduce is the norm: the
>>>> volunteers look for similar bug reports, categorize them and forward to
>>>> relevant teams.
>>>
>>> I fail to see how this would be useful.
>>
>> It saves time for other people.
> 
> Not IME.

Would save time for me.

>> For instance, I would be delighted to be able to see the list of bugs
>> that someone at some point thought I could take care of best (as, say,
>> tagged me as their owner).
> 
> This is only relevant for issues created before you took charge.

Nope. Even now I would very much like to see the lists of bug I fixed, 
ones I triaged but then got sidetracked, and ones I missed because of 
bad naming, or because I accidentally marked an email as read but then 
forgot to reply.

> The
> ones created after that arrive to you one by one; how many seconds
> does it take for you to understand whether an issue is in your area or
> not?

Usually, not a lot. Though there are exceptions. That's largely 
irrelevant, though. See above.

>> They don't have to find out the reason with 100% certainty. A lot of the
>> time, the general area of responsibility is pretty obvious (Ruby
>> support? tag with 'ruby'!)
> 
> Your examples are of the kind that is quite rare in Emacs maintenance.
> Most of the bug reports are nowhere near being so clearly classified.

And yet, I'm fairly sure about the Gnus/Tramp/EWW bug reports I'm seeing 
lately.

> Even a problem with Ruby support could be due to something much
> deeper, like syntax or font-lock or even regular expressions.  That is
> why I said that figuring out the subsystem is a large part of finding
> the cause.

It's no trouble if the original assignee finds that the problem is in 
another subsystem and forwards it to someone else later.

> It could be that a quick-and-dirty classification of this kind is of
> some help, assuming the person who is responsible for Ruby is active
> enough to quickly take a look and reassign to someone else if needed.
> (But if he/she is active, then why didn't they respond in the first
> place?)

People have lives, and this kind of system would allow certain feature 
owners to unsubscribe from all bugs, and yet handle bugs they are 
equipped to handle. That could keep some otherwise busy people 
semi-active in Emacs development.

> However, even under this assumption, what do you do with
> reports related to code in simple.el or in faces.el or in frame.el?
> Emacs is an old and very stable project, so a large portion of
> reported issues are not simple bugs in a recent commit.

Forward to "core", or something. I would say that these kind of bugs are 
a minority, though.

>> I think having all bugs assigned but without a personal message is still
>> better than not having all bugs assigned.
> 
> I don't see how that would be better.  People who are motivated to
> work on bugs read the bug list anyway, and people who are less
> motivated are known not to respond to direct emails for weeks and
> months on end.

I think there's a place for the middle ground. Especially if there's 
suddenly a jump in Emacs's popularity, and the flow of bug reports 
increases significantly.

> We are not an enterprise where a manager can cause
> subordinates to get their act together by showing a list of assigned
> but unhandled issues, so having a list of many unhandled issues
> assigned to someone specific is of no particular importance for
> resolving the issues, no better than having a list of unhandled issues
> disregarding any assignments.

That is also true. Even having an efficient triage strategy won't make 
up for the lack of people dealing with the actual bugs.

>>> Not sure why this is important: IME, such messages are in many cases
>>> of little help in investigating the issue and finding its causes.
>>
>> Again: knowing that the bug is still reproducible and knowing it still
>> bothers people. Is that not useful in your book?
> 
> Very little, and in some cases not at all.

Okay then. I have found it helpful many times.

>> Also, users describe their workarounds, offer their half-baked
>> solutions, and even sometimes end up offering patches. This, again, IME
>> happens more often in my projects that use the GitHub issue tracker.
> 
> "More often" than what?

Than for packages inside Emacs core that I maintain.

> And why do you think the frequency of that is
> related to the issue tracker being used?

Because one bug tracker is easy for an average user to interact with, 
and another is not.

> Could it perhaps be related
> to the relative complexity of the projects being compared?

Unlikely. I'm comparing third-party Emacs packages here with the core 
ones. So it's the same userbase and the effect is pretty apparent across 
packages with different complexities.

As one example, js-mode probably has a lot more actual users than 
js2-mode, but there are significantly more bug reports in the latter's 
bug tracker, and a lot of them are about issues present in both packages 
(e.g. certain indentation problems, or support for new language features).

It even comes to this: for most bug reports regarding indentation in 
js2-mode I usually reply to report them to js-mode instead (because 
js2-mode delegates to js-mode for indentation), and only a very small 
fraction of users actually file said reports with 'M-x report-emacs-bug'.

>>> If the advice is readily available and discoverable, it might help
>>> others.
>>
>> To really be discoverable it would need to be easy to use from the web
>> interface. Like them or not, they are popular, and they're here to stay.
> 
> The entire contents of the Emacs repository is reachable from a
> browser, so this is not an issue.

Reachability doesn't equate to ease of use.

>> At this point we're drowning in nested subthreads
> 
> We are?  I see only 2 subthreads: this one, and that other one, where
> my message didn't see any responses that discuss my concerns.

I can just say that it wasn't trivial to find this exact email and 
finally respond to it.

Not sure I can describe the alternative well, but when discussions are 
led in issues in GitHub or GitLab, there's no threading, each discussion 
is displayed as flat in the UI. And that often makes them more focused. 
If there's a branch that deserves additional discussion, a new issues 
can be filed and linked to from the original one.

So for the present discussions I could create several interlinked issues:

- Benefits/drawbacks of the switch.
- The details of the new workflow, what will have to change.
- The actual progress of the transition.

>>>> Bug handling is "easier" than doing code reviews in a lot of respects.
>>>
>>> IME, it's actually the other way around, assuming that "bug handling"
>>> includes all the way until the bug's root causes are revealed and
>>> understood.
>>
>> By "easier", I mean technically simpler, in terms of UI features
>> involved. So the said features would be easier to re-implement in a
>> dedicated Emacs-based client.
> 
> If you say so.  My point was that having those features is much more
> important than having features that facilitate patch review.

No argument from me here.

Re: [RFE] Migration to gitlab

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Again:
>
> - Searching the bug tracker for duplicates.
> - Tagging the bug.
> - Changing priority.
> - Closing it as a duplicate, maybe.
>
> All of these require interacting with Debbugs. Usually through the
> control server.

I haven't followed this discussion closely, so I don't know whether
anybody's mentioned this before: Emacs does have a way to interact with
the Emacs bug tracker through the debbugs-gnu package.  I don't know
whether anybody else uses it to do bug triage but me, though.  :-)

It allows you to do all those things you mention (except searching bug
report bodies) without knowing anything about debbugs syntax.

It's got some problems, though: The initial time it uses to display the
list of bugs is long (15 seconds), and there's no way to update the list
without re-fetching the entire list, which is a bore.  But the debbugs
API just doesn't have any way to say "get bug reports that have changed
since <time>".

It would also be nice if Emacs had (as part of report-bug, perhaps) a
way to search bugs, so that users could see whether anybody else had
reported the same thing, but again, the debbugs API isn't very...
er...  expressive?

> Or, in the case of search, it's usually more intuitive and, most
> importantly, *faster*.

A better search of the bug database would be great; yes.

Anyway, it's obvious that most younger programmers prefer the
Git{hub,lab} way of doing things -- if only because that's the only way
they've done this sort of thing before.  And it would be great if Emacs
could cater to that programming pool, too.

But personally, I just loathe interacting with bug reports and patches
through a web browser, and I hate the "accept the pull request" thing,
because I want to test the patch locally on my own machine first, and I
want to be able to fix up really minor syntax things myself before
committing without brow-beating the patch submitter repeatedly to get
them to fix up these things minor before accepting the patch.

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

Re: [RFE] Migration to gitlab

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Or, in the case of search, it's usually more intuitive and, most
>> importantly, *faster*.
>
> A better search of the bug database would be great; yes.

Oh; I forgot about `debbugs-gnu-search', which seems to provide a very
fast full text search of the bug database...

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

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 15.05.2019 8:42, Lars Ingebrigtsen wrote:
> Oh; I forgot about `debbugs-gnu-search', which seems to provide a very
> fast full text search of the bug database...

It's, uh, moderately fast, provided the search phrase doesn't result in 
too many matches.

It's also not something an average user will think of using.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  theophilusx@gmail.com,  hi-angel@yandex.ru,  emacs-devel@gnu.org
> Date: Wed, 15 May 2019 07:42:42 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >> Or, in the case of search, it's usually more intuitive and, most
> >> importantly, *faster*.
> >
> > A better search of the bug database would be great; yes.
> 
> Oh; I forgot about `debbugs-gnu-search', which seems to provide a very
> fast full text search of the bug database...

It depends on what you are looking for.  Searching for duplicates is
tricky if it uses just plain text, because in many cases it's not
clear what text to search for.  And even in other cases, a lot of my
searches hit uninteresting parts of the report body, e.g. the part
that describes the system/Emacs configuration and linked-in libraries.
A search that ignores certain parts of the reports, and generally is
more intelligent about those parts, would be a significant
improvement.

Re: [RFE] Migration to gitlab

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It depends on what you are looking for.  Searching for duplicates is
> tricky if it uses just plain text, because in many cases it's not
> clear what text to search for.

Yeah...  but wouldn't that be the case in any search-based system?
Whether a thing is a duplicate or not takes a lot of human judgement. 

> And even in other cases, a lot of my searches hit uninteresting parts
> of the report body, e.g. the part that describes the system/Emacs
> configuration and linked-in libraries.  A search that ignores certain
> parts of the reports, and generally is more intelligent about those
> parts, would be a significant improvement.

Yes, that is true.

I wonder what would happen if we stuck those bits in an attachment?
That should make it easier to filter out those bits, but I don't know
whether debbugs supports that.

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  theophilusx@gmail.com,  hi-angel@yandex.ru,  emacs-devel@gnu.org
> Date: Thu, 16 May 2019 05:57:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It depends on what you are looking for.  Searching for duplicates is
> > tricky if it uses just plain text, because in many cases it's not
> > clear what text to search for.
> 
> Yeah...  but wouldn't that be the case in any search-based system?
> Whether a thing is a duplicate or not takes a lot of human judgement. 

We could add keywords to each bug, then the search could be more
intelligent.  Bonus points for writing a Lisp program to find such
keywords automatically ;-)

> > And even in other cases, a lot of my searches hit uninteresting parts
> > of the report body, e.g. the part that describes the system/Emacs
> > configuration and linked-in libraries.  A search that ignores certain
> > parts of the reports, and generally is more intelligent about those
> > parts, would be a significant improvement.
> 
> Yes, that is true.
> 
> I wonder what would happen if we stuck those bits in an attachment?
> That should make it easier to filter out those bits, but I don't know
> whether debbugs supports that.

For starters, perhaps we could make debbugs-gnu smarter, as the
beginning of that section can be easily identified.

Re: [RFE] Migration to gitlab

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I wonder what would happen if we stuck those bits in an attachment?
>> That should make it easier to filter out those bits, but I don't know
>> whether debbugs supports that.
>
> For starters, perhaps we could make debbugs-gnu smarter, as the
> beginning of that section can be easily identified.

As far as I can tell by peering at the debbugs-gnu code, the search is
done server side, so this would require somebody who can hack the
debbugs source code (and deploy on the server).

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  theophilusx@gmail.com,  hi-angel@yandex.ru,  emacs-devel@gnu.org
> Date: Thu, 16 May 2019 15:48:37 +0200
> 
> > For starters, perhaps we could make debbugs-gnu smarter, as the
> > beginning of that section can be easily identified.
> 
> As far as I can tell by peering at the debbugs-gnu code, the search is
> done server side

Too bad, I though it was in our code.

debbugs extensions (was: [RFE] Migration to gitlab)

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > For starters, perhaps we could make debbugs-gnu smarter, as the
>> > beginning of that section can be easily identified.
>>
>> As far as I can tell by peering at the debbugs-gnu code, the search is
>> done server side
>
> Too bad, I though it was in our code.

For the records, the part of the search engine which is used inside the
SOAP API was written by me, and brought to debbugs.gnu.org. I've asked
the Debian BTS guys for merging upstream; there hasn't been any positive
answer ever.

So in theory, we could continue to add our own extensions,
server-side. Unfortunately, I'm short in time, and don't see the
possibility to do this myself in the foreseen future. And I have already
pending TODOs for debbugs, which I'm sad not to have the time to work on.

Best regards, Michael.

Re: debbugs extensions (was: [RFE] Migration to gitlab)

[Noam Postavsky]

On Thu, 16 May 2019 at 10:42, Michael Albinus <michael.albinus@gmx.de> wrote:

> For the records, the part of the search engine which is used inside the
> SOAP API was written by me, and brought to debbugs.gnu.org. I've asked
> the Debian BTS guys for merging upstream; there hasn't been any positive
> answer ever.

In the master branch of Debian's debbugs, there are some changes to
use an actual database; the main motivation, as far as I understand,
is to improve searching. So maybe if we incorporate that stuff the
searching can be improved (it's not part of the debbugs that Debian is
currently using, I think, which is what I'm currently targetting for
rebase).

https://debconf17.debconf.org/talks/103/
Slides: https://annex.debconf.org/debconf-share/debconf17/slides/103-debbugs_22_years_of_bugs.pdf

Re: debbugs extensions

[Michael Albinus]

Noam Postavsky <npostavs@gmail.com> writes:

Hi Noam,

>> For the records, the part of the search engine which is used inside the
>> SOAP API was written by me, and brought to debbugs.gnu.org. I've asked
>> the Debian BTS guys for merging upstream; there hasn't been any positive
>> answer ever.
>
> In the master branch of Debian's debbugs, there are some changes to
> use an actual database; the main motivation, as far as I understand,
> is to improve searching. So maybe if we incorporate that stuff the
> searching can be improved (it's not part of the debbugs that Debian is
> currently using, I think, which is what I'm currently targetting for
> rebase).

It's not only about performance. It's also about false hits. If you
apply debbugs-gnu-search for "flymake", in the package "emacs", you get
1009 bugs. Most of them are not about a flymake problem, but they are
hit because "flymake" belongs to the list of features, compiled by
report-emacs-bug automatically.

This shall be improved by excluding such false hits, because you want
only the bug reports about flymake problems.

Best regards, Michael.

Re: debbugs extensions

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Lars Ingebrigtsen <larsi@gnus.org>,  theophilusx@gmail.com,  Dmitry Gutov <dgutov@yandex.ru>,  Konstantin Kharlamov <hi-angel@yandex.ru>,  Emacs developers <emacs-devel@gnu.org>
> Date: Fri, 17 May 2019 09:30:52 +0200
> 
> It's not only about performance. It's also about false hits. If you
> apply debbugs-gnu-search for "flymake", in the package "emacs", you get
> 1009 bugs. Most of them are not about a flymake problem, but they are
> hit because "flymake" belongs to the list of features, compiled by
> report-emacs-bug automatically.
> 
> This shall be improved by excluding such false hits, because you want
> only the bug reports about flymake problems.

Actually, we only want to exclude that by default, because in some
(rare) cases, you may wish to do something with all the reports whose
list of features includes flymake.

So we need a control to turn this on when needed.

Re: debbugs extensions

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> It's not only about performance. It's also about false hits. If you
>> apply debbugs-gnu-search for "flymake", in the package "emacs", you get
>> 1009 bugs. Most of them are not about a flymake problem, but they are
>> hit because "flymake" belongs to the list of features, compiled by
>> report-emacs-bug automatically.
>>
>> This shall be improved by excluding such false hits, because you want
>> only the bug reports about flymake problems.
>
> Actually, we only want to exclude that by default, because in some
> (rare) cases, you may wish to do something with all the reports whose
> list of features includes flymake.
>
> So we need a control to turn this on when needed.

Maybe somebody writes a wishlist report about? No guarantee it will be
implemented soon, but we shall track it.

Best regards, Michael.

Re: debbugs extensions

[Noam Postavsky]

On Fri, 17 May 2019 at 03:30, Michael Albinus <michael.albinus@gmx.de> wrote:

> >> For the records, the part of the search engine which is used inside the
> >> SOAP API was written by me, and brought to debbugs.gnu.org. I've asked
> >> the Debian BTS guys for merging upstream; there hasn't been any positive
> >> answer ever.
> >
> > In the master branch of Debian's debbugs, there are some changes to
> > use an actual database; the main motivation, as far as I understand,
> > is to improve searching. So maybe if we incorporate that stuff the
> > searching can be improved (it's not part of the debbugs that Debian is
> > currently using, I think, which is what I'm currently targetting for
> > rebase).
>
> It's not only about performance. It's also about false hits.

I meant, proposing search API changes on top of the new and improved
database search might be better received than previous proposals.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 15.05.2019 5:30, Lars Ingebrigtsen wrote:

> I haven't followed this discussion closely, so I don't know whether
> anybody's mentioned this before: Emacs does have a way to interact with
> the Emacs bug tracker through the debbugs-gnu package.

Several times, yes. And I've responded: it is still slower than 
GitHub/GitLab. And I don't have SMTP configured in Emacs.

I'm not a big fan of the UI either, but that's secondary.

> It would also be nice if Emacs had (as part of report-bug, perhaps) a
> way to search bugs, so that users could see whether anybody else had
> reported the same thing, but again, the debbugs API isn't very...
> er...  expressive?

I think it did have that at some point?.. Or maybe I just dreamt that.

> Anyway, it's obvious that most younger programmers prefer the
> Git{hub,lab} way of doing things -- if only because that's the only way
> they've done this sort of thing before.  And it would be great if Emacs
> could cater to that programming pool, too.

Yup.

> But personally, I just loathe interacting with bug reports and patches
> through a web browser, and I hate the "accept the pull request" thing,
> because I want to test the patch locally on my own machine first, and I
> want to be able to fix up really minor syntax things myself before
> committing without brow-beating the patch submitter repeatedly to get
> them to fix up these things minor before accepting the patch.

I don't understand the hate on an optional feature: you could still 
download the patch, fix it up yourself, push and close. It can even be 
automated without too much difficulty. Or you can merge and push the 
minor fix-ups in a follow-up commit.

"Brow-beating" the submitter, as you phrased it, could be beneficial as 
well if the person is interested in contributing more than one patch.

Re: [RFE] Migration to gitlab

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I don't understand the hate on an optional feature: you could still
> download the patch, fix it up yourself, push and close.

If Emacs doesn't have an interface to the pull request tracker, then
downloading the patch is a lot more work (for me) than applying patches
from people now, which is basically a couple of keystrokes now.  (Except
the fixing-up part, of course.)

> It can even be automated without too much difficulty. Or you can merge
> and push the minor fix-ups in a follow-up commit.

I generally thing stylistic fix-ups in a follow-up commits is a bad
idea -- when other people later `C-x v g' to see what's going on, the
fixed-up lines will obscure the functional change.  Which is annoying.

> "Brow-beating" the submitter, as you phrased it, could be beneficial
> as well if the person is interested in contributing more than one
> patch.

Yes, mentoring submitters towards the expected style is useful, but
certain nit-picks just isn't worth it.

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

Re: [RFE] Migration to gitlab

[Ricardo Wurmus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I remember certain people on this mailing list complaining about
> duplicates in the bug tracker (and users failing to do the
> search). Well, get a bug tracker with a user friendlier interface
> (visibility, searchability, etc), and the users will do more work for
> you.

I have no opinion on migrating to Gitlab, but I’d like to note that
there are other web interfaces for Debbugs, such as Mumi:

    https://git.elephly.net/gitweb.cgi?p=software/mumi.git

It’s used by Guix, but it really works for all of the GNU Debbugs
instance:

    https://issues.guix.info/

Here’s an Emacs bug, for example:

    https://issues.guix.info/issue/32189

It’s got many bugs and is kinda slow because it really just talks to to
the Debbugs SOAP interface without any smart caching, but it
demonstrates syntax / patch highlighting, colours, and things like that.

I’m not happy with the search and will eventually switch to indexing
messages locally instead of using the Debbugs search.  It might be
easier to fix annoyances and obstacles in Debbugs than to plan a big
migration to Gitlab, dunno.

--
Ricardo

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 26.04.2019 11:42, Ricardo Wurmus wrote:
> I have no opinion on migrating to Gitlab, but I’d like to note that
> there are other web interfaces for Debbugs, such as Mumi:
> 
>      https://git.elephly.net/gitweb.cgi?p=software/mumi.git
> 
> It’s used by Guix, but it really works for all of the GNU Debbugs
> instance:
> 
>      https://issues.guix.info/
> 
> Here’s an Emacs bug, for example:
> 
>      https://issues.guix.info/issue/32189

It's nicer that the Debbugs UI for sure, including a better dashboard 
(recent activity, priority bugs, the search input field with tips; a bug 
report ends with "send email to xxx to leave a comment"), which is a 
step forward in user-friendliness.

It still lacks a lot of features that GitLab has, though. Let's talk 
about that in a different thread.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 19.03.2019 20:15, Eli Zaretskii wro

> Savannah UI and Savannah are not identical, far from that.

I wasn't saying that. I was saying, though, that the rest is not 
particularly unique as far as features go.

> Such automated checking is n ot easy to set up, because the copyright
> assignment database includes some details that are private and cannot
> be exposed to public interfaces.  So someone will have to come up with
> a service that publishes only the public parts of that, and even then
> there will be some rare cases where a manual check will be needed.

If the Gitlab server is spinning somewhere inside the FSF 
infrastructure, it could access the copyright assignment database 
privately, be it via a private HTTP service, or some other way.

> It is all too easy to disable/bypass the hooks, as you probably know
> very well.  So this doesn't sound like an important issue to me.

I can find out, but no, I don't know/remember that well. I don't often 
have to deal with complex commit hooks.

Konstantin's point about aborting a commit and losing the already-typed 
commit message seems quite valid as well (not everybody uses VC, I guess).

>> Further, documentation could be in a separate commit
> 
> It shouldn't be.

Well... ¯\\_(ツ)_/¯

Also please keep in mind that a significant fraction of Git users do 
haphazard commits and then rebase/amend them later before pushing.

> If that was the only sentence in that message, I probably wouldn't
> have responded at all.  The purpose of my response was to provide a
> more balanced picture to those who might be unaware of the details.

I hope it was appreciated.

Re: [RFE] Migration to gitlab

[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 will not move Emacs to Gitlab.  That site has substantial flaws on
some ethical points, and we do not endorse it.

See https://gnu.org/software/repo-criteria.html for more details.

Changing savannah's interface is something we could do,
if people offer to do the work.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [RFE] Migration to gitlab

[Tim Cross]

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

While not disagreeing with the decision, it is probably worth noting that
GitLab is not just a repository hosting service in the same vain as Github.
GitLab is software which can be installed on a GNU/Linux server. My
impression was that the OP was proposing to use the software rather than
the repository hosting service. The software uses an MIT license.

On Mon, 18 Mar 2019 at 12:48, Richard Stallman <rms@gnu.org> 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. ]]]
>
> We will not move Emacs to Gitlab.  That site has substantial flaws on
> some ethical points, and we do not endorse it.
>
> See https://gnu.org/software/repo-criteria.html for more details.
>
> Changing savannah's interface is something we could do,
> if people offer to do the work.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: [RFE] Migration to gitlab

[Van L]

You write:

> My impression was that the OP was proposing to use the software rather
> than the repository hosting service. The software uses an MIT license.

The org-mode documentation links from info nodes to webpages sitting on
Gogs. It too is under the MIT License.

  https://gogs.io/

>  We will not move Emacs to Gitlab.

That is good news.

-- 
© 2019 Van L
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
"What's so strange when you know that you're a Wizard at 3?" -Joni Mitchell

Re: [RFE] Migration to gitlab

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

  > GitLab is software which can be installed on a GNU/Linux server. 

That is something we could consider.
However, to do it right would call for integrating it with Savannah.
-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 19.03.2019 4:15, 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. ]]]
> 
>    > GitLab is software which can be installed on a GNU/Linux server.
> 
> That is something we could consider.
> However, to do it right would call for integrating it with Savannah.

What integration do you have in mind?

Since the development of Gitlab is a lot more active, in the long run it 
might be easier to write whatever bridge is necessary on Savannah's side.

Re: [RFE] Migration to gitlab

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

  > > That is something we could consider.
  > > However, to do it right would call for integrating it with Savannah.

  > What integration do you have in mind?

Making the software from GitLab work together smoothly with the
rest of the Savannah software.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [RFE] Migration to gitlab

[Karl Fogel]

On 17 Mar 2019, Richard Stallman wrote:
>We will not move Emacs to Gitlab.  That site has substantial flaws on
>some ethical points, and we do not endorse it.
>
>See https://gnu.org/software/repo-criteria.html for more details.
>
>Changing savannah's interface is something we could do,
>if people offer to do the work.

Saying "we will not move X to GitLab" is ambiguous -- not your fault -- because the maintainers of GitLab use that word to refer to several distinct things:

1) A rather nice Free Software package that offers functionality similar to Savannah and other forges.

2) A hosted service for (1).

3) A hosted service for a version of (1) that has been extended with proprietary features.

I believe that (1) and (2) both meet the repository criteria you mention above.  (3) obviously does not.

"GitLab" is also the name of a company that runs both (2) and (3), and that company is the primary maintainer of (1).  While their marketing material focuses on (3), making it hard to tell that they also offer (2), they do offer (2).  Of course, one could just self-host (1), if one has the ability to do so.

Best regards,
-Karl

Re: [RFE] Migration to gitlab

[Eric Abrahamsen]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> <hi-angel@yandex.ru> написал:
>> I want to start by answering first likely question: the Community
>> Edition of gitlab should be fine license-wise, quoting Richard
>> Stallman "We have a simple way of looking at these two versions. The
>> free version is free software, so it is ethical."¹
>>
>> Terms: "merge request" in gitlab means "patch series sent for review".
>>
>> ----
>>
>> It makes me sad, seeing Emacs addons popping up, for a functional
>> that better could've been implemented in core. It's a lot of
>> contributors out there; at the same time, I see very little patches
>> on emacs-devel list.
>>
>> A lot of open-source projects already migrated to gitlab: all
>> FreeDesktop projects, all Gnome projects; and KDE are likely to
>> migrate soon too². Gnome reports: "After switching to GitLab, I
>> noticed almost immediately an increase in contributions from people
>> I hadn’t met before. I think GitLab really lowered the threshold for
>> people getting started"³.
>>
>> So, at the very least, migrating to gitlab should make contributions
>> easier for bigger part of the open-source world, peoples who used to
>> github and gitlab. (btw, here's a rarely mentioned point, why in
>> particular mailing-list workflow is hard for newcomers: almost every
>> mail client out there breaks formatting by default; and configuring
>> that out isn't always easy).
>>
>> Other points include:
>> 	1. I know some people like to operate with mails rather than
>> web-interface (which is what usual gitlab workflow based on). For
>> them gitlab can be configured to be managed with mails. I don't know
>> how far it stretches, but at the very least creating/replying to
>> issues/merge requests can be enabled.⁴
>> 	2. Gitlab makes addressing review comments easier. With
>> mailing lists workflow you either need to α) send a v2 of the patch;
>> which is a little frustrating: you need to find message-id to feed
>> it to git-send-email, and then you need to make sure its title lines
>> up with the rest of the series. Or β) resend whole patch-series;
>> which can be just redundant when all you did was a one-line change,
>> and clutters the mailing list. Also, upon sending v3, v4, etc. you
>> need to save somewhere changes since v1. You can put it in actual
>> commits, but for git-history this information is unnecessary. With
>> gitlab workflow, on the other hand, you just force-push changes to
>> the branch that has merge-request opened. A single command, that it.
>> 	3. CI. I've recently seen someone on emacs-devel⁵ asking a
>> contributor to run their syntax-checking script on a regular basis.
>> That's becase you can't run any check on a code hanging out there on
>> a mailing list in pure air. Gitlab supports CI, i.e. one can set it
>> up to run unit-tests for every merge-request created, so these
>> errors get caught before getting to the tree; and possibly even
>> before getting to eyes of reveiwers.
>> 	4. Impossible to lose "merge request". I've seen in Emacs docs
>> an advice to send patch series to a bugtracker, because on
>> emacs-devel they can easily be forgotten. That can't happen so
>> easily with gitlab, where you have a tab with open merge requests.
>> 	5. Discussion on patch series is easier to read. On mailing
>> lists can quickly appear a dozen of no longer relevant review mails,
>> that refer to something that was addressed. In Gitlab the addressed
>> comments can be marked as such, and get collapsed.
>> 	6. More tightly integrated bugtracker. When a commit refers to
>> an issue, it can be seen from inside the issue. This is useful e.g.
>> when someone fixed a problem, but for some reason couldn't address
>> review comments, leaving the code behind. Then later peoples who
>> stumble upon the same issue can just improve the code instead of
>> doing research and writing it on their own.
>> 	7. Unclear how to download a patch-series from mailing list.
>> Usually mailing-list driven projects add some system that tracks
>> patches, and allows to download series. E.g. that's how Mesa worked.
>> But Emacs don't seem to have one. With gitlab though you can simply
>> fetch someone's branch.
>>
>> 1:
>> https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
>> 2:
>> http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
>> 3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
>> 4: https://docs.gitlab.com/ee/administration/incoming_email.html
>> 5: http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html
>
> Btw, one more point I just got: no more discrepancy between what
> mailing list subscribers see, and what web-interface renders. E.g. the
> nicely formatted list of points above from the outside worls looks
> like a large single line:
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html

Not to muddy the waters further, but Source Hut (or Sir Hat) is a newish
"forge" that seems very much in line with Emacs' aesthetic, and provides
extensive integration with mailing lists. Might be a nice middle ground.

https://man.sr.ht/

Re: [RFE] Migration to gitlab

[Amin Bandali]

On 2019-03-17  9:48 AM, Eric Abrahamsen wrote:
[...]
>
> Not to muddy the waters further, but Source Hut (or Sir Hat) is a newish
> "forge" that seems very much in line with Emacs' aesthetic, and provides
> extensive integration with mailing lists. Might be a nice middle ground.
>
> https://man.sr.ht/
>
>

Seconding sourcehut [0].  Same topic (migration to GitLab) came up on
another GNU list a while ago and I wrote a brief reply with my thoughts
on sourcehut vs other common web-based software forges here [1].  IMHO
sourcehut’s main selling point is its treatment of email as first class
citizen, along with a simple, clutter- and distraction-free, and mostly
JS-free web interface; as opposed to a bloated and sluggish web app
built on the shiniest trendy JS framework that likes to eat up all the
memory on the user’s machine while offering an arguably inferior user
experience and flexibility.

[0]: https://sourcehut.org
[1]: https://lists.gnu.org/r/guile-devel/2019-01/msg00027.html

IMHO in a not-so-distant future sourcehut could be a promising candidate
for a more modern and featureful, yet lean and usable alternative to
Savannah.

bug#34889: [RFE] Migration to gitlab

[Eli Zaretskii]

tags 34889 notabug
thanks

I'm closing this because it is not a bug.  Please continue the
discussion on emacs-devel, but please don't cross-post to the bug
tracker.

bug#34889: [RFE] Migration to gitlab

[Konstantin Kharlamov]

Hmm, okay, but then where feature-requests supposed to go?

В Вс, мар 17, 2019 at 6:39 ДП (AM), Eli Zaretskii 
<eliz@gnu.org> написал:
> tags 34889 notabug
> thanks
> 
> I'm closing this because it is not a bug.  Please continue the
> discussion on emacs-devel, but please don't cross-post to the bug
> tracker.

bug#34889: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sun, 17 Mar 2019 07:04:57 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 34889-done@debbugs.gnu.org
> 
> Hmm, okay, but then where feature-requests supposed to go?

Requests to add features to Emacs should indeed be sent to the
tracker.  But you were raising an issue with the Emacs development
process, not with the Emacs software.  So the proper place to discuss
what you wanted is on emacs-devel.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sun, 17 Mar 2019 05:17:50 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> I want to start by answering first likely question: the Community 
> Edition of gitlab should be fine license-wise, quoting Richard Stallman 
> "We have a simple way of looking at these two versions. The free 
> version is free software, so it is ethical."¹

Please don't cross-post to the bug tracker.  I've closed the bug
opened by the initial report.  Please continue the discussion only
here.

Thanks.

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

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

>
> A lot of open-source projects already migrated to gitlab: all
> FreeDesktop projects, all Gnome projects; and KDE are likely to migrate
> soon too². Gnome reports: "After switching to GitLab, I noticed almost
> immediately an increase in contributions from people I hadn’t met
> before. I think GitLab really lowered the threshold for people getting
> started"³.
>

I agree. I contribute often on github/gitlab, and the process is very
simple. In comparison, Emacs has hurdles that requires much more motivation
and persistance in order to contribute.

I think it boils down to this: on github/gitlab, almost everything is
handled by git itself: you propose/test changes by creating/pulling
branches on the repository/fork... so you basically only need to use git
and click a few buttons in the browser (or use magithub/emacs-gitlab etc).
With the Emacs model, you need to go back & forth between emails and git,
copying patches, applying them, keeping track of where each changes is,
etc. The extra step does not look like much but it is a lot, especially for
simple changes.



>         4. Impossible to lose "merge request". I've seen in Emacs docs an
> advice to send patch series to a bugtracker, because on emacs-devel
> they can easily be forgotten. That can't happen so easily with gitlab,
> where you have a tab with open merge requests.
>

Yeah, the maintainer job is easier, no need to remember which topics are
the active ones. Searching for existing or past similar issues also feels
simpler, but I guess that is just habit.



>         5. Discussion on patch series is easier to read. On mailing lists
> can
> quickly appear a dozen of no longer relevant review mails, that refer
> to something that was addressed. In Gitlab the addressed comments can
> be marked as such, and get collapsed.
>

It's also easier to view the current states of the commits, you don't need
to search for the latest patch in the list of emails.

Now, the Emacs model is similar to the linux kernel dev & the git dev
workflow, so obviously "it works fine" and has advantages too, but
personally I think those are outweighted by the the disadvantages (or
rather than the contribution experience is much nicer with gitlab).

Kind regards,
Philippe

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

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Sun, Mar 17, 2019 at 1:54 PM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
> Now, the Emacs model is similar to the linux kernel dev & the git dev workflow, so obviously "it works fine" and has advantages too, but personally I think those are outweighted by the the disadvantages (or rather than the contribution experience is much nicer with gitlab).

IMO, I feel more comfortable with the current Emacs model because I
see less noise in the interface.  Furthermore, the current model
allows me to do my own way of automation against a stable simple
interface (plain-text e-mails and textual command lines have been
around for a long time).  This may not be welcoming to newcomers, but
I once was a newcomer in the Linux kernel dev but found nothing so
difficult about it.

> Kind regards,
> Philippe

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo 
<tadeus.prastowo@unitn.it> написал:
> On Sun, Mar 17, 2019 at 1:54 PM Philippe Vaucher
> <philippe.vaucher@gmail.com> wrote:
>>  Now, the Emacs model is similar to the linux kernel dev & the git 
>> dev workflow, so obviously "it works fine" and has advantages too, 
>> but personally I think those are outweighted by the the 
>> disadvantages (or rather than the contribution experience is much 
>> nicer with gitlab).
> 
> IMO, I feel more comfortable with the current Emacs model because I
> see less noise in the interface.  Furthermore, the current model
> allows me to do my own way of automation against a stable simple
> interface (plain-text e-mails and textual command lines have been
> around for a long time).  This may not be welcoming to newcomers, but
> I once was a newcomer in the Linux kernel dev but found nothing so
> difficult about it.

The automation sounds a bit abstract, but I guess you still can do it 
if gitlab have enabled replying/opening of merge requests through mails.

Also, Linux kernel and git has "patchwork" site that essentially tracks 
open patch-series, versions of patches, comments to them, allows to 
download latest series… It is more advanced than just the mailing 
list as GNU Emacs has.

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
>
>
>
> В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo
> <tadeus.prastowo@unitn.it> написал:
> > IMO, I feel more comfortable with the current Emacs model because I
> > see less noise in the interface.  Furthermore, the current model
> > allows me to do my own way of automation against a stable simple
> > interface (plain-text e-mails and textual command lines have been
> > around for a long time).  This may not be welcoming to newcomers, but
> > I once was a newcomer in the Linux kernel dev but found nothing so
> > difficult about it.
>
> The automation sounds a bit abstract,

The automation of copying and pasting message-id and the like.

> but I guess you still can do it
> if gitlab have enabled replying/opening of merge requests through mails.

As you wrote in the initial e-mail, e-mails are not the primary means
of gitlab model, and so, how far it can be stretched and how long it
will keep being supported remain to be seen.  Seeing the stretching is
rather easy because it can be done now.  But, it is impossible to see
how long it will keep being supported in the gitlab model.

> Also, Linux kernel and git has "patchwork" site that essentially tracks
> open patch-series, versions of patches, comments to them, allows to
> download latest series… It is more advanced than just the mailing
> list as GNU Emacs has.

Yes, as you pointed out in the initial e-mail, a mailing list itself
is not enough.  That causes the chore of copying and pasting and the
like, which can be automated, especially if Emacs is used.  The
perspective that I support is that of heterogeneity.  IMO, the gitlab
model is into homogeneity: one uniform system for everything, but that
sacrifices flexibility.

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Вс, мар 17, 2019 at 4:49 ПП (PM), Tadeus Prastowo 
<tadeus.prastowo@unitn.it> написал:
> On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov 
> <hi-angel@yandex.ru> wrote:
>> 
>> 
>> 
>>  В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo
>>  <tadeus.prastowo@unitn.it> написал:
>>  > IMO, I feel more comfortable with the current Emacs model because 
>> I
>>  > see less noise in the interface.  Furthermore, the current model
>>  > allows me to do my own way of automation against a stable simple
>>  > interface (plain-text e-mails and textual command lines have been
>>  > around for a long time).  This may not be welcoming to newcomers, 
>> but
>>  > I once was a newcomer in the Linux kernel dev but found nothing so
>>  > difficult about it.
>> 
>>  The automation sounds a bit abstract,
> 
> The automation of copying and pasting message-id and the like.
> 
>>  but I guess you still can do it
>>  if gitlab have enabled replying/opening of merge requests through 
>> mails.
> 
> As you wrote in the initial e-mail, e-mails are not the primary means
> of gitlab model, and so, how far it can be stretched and how long it
> will keep being supported remain to be seen.  Seeing the stretching is
> rather easy because it can be done now.  But, it is impossible to see
> how long it will keep being supported in the gitlab model.

Sure this part is just a contemplation, but I think that usage of 
emails was added to gitlab in the first place to keep workflow of 
peoples who got used to mailing lists. In that case I'd expect this to 
be enhanced rather than removed in the future (of course in the end 
this depends on demand or contributions from other peoples. And you are 
a creator of that demand).

>>  Also, Linux kernel and git has "patchwork" site that essentially 
>> tracks
>>  open patch-series, versions of patches, comments to them, allows to
>>  download latest series… It is more advanced than just the mailing
>>  list as GNU Emacs has.
> 
> Yes, as you pointed out in the initial e-mail, a mailing list itself
> is not enough.  That causes the chore of copying and pasting and the
> like, which can be automated, especially if Emacs is used.  The
> perspective that I support is that of heterogeneity.  IMO, the gitlab
> model is into homogeneity: one uniform system for everything, but that
> sacrifices flexibility.

I just don't see how could gitlab workflow interfere with that. If 
anything, it helps automating the chore of copying and pasting, because 
now you can get someone's series by a simple `git fetch remote branch`.

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Sun, Mar 17, 2019 at 3:06 PM Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
> В Вс, мар 17, 2019 at 4:49 ПП (PM), Tadeus Prastowo
> <tadeus.prastowo@unitn.it> написал:
> > On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov
> > <hi-angel@yandex.ru> wrote:
> >>  The automation sounds a bit abstract,
> >
> > The automation of copying and pasting message-id and the like.
> >
> >>  but I guess you still can do it
> >>  if gitlab have enabled replying/opening of merge requests through
> >> mails.
> >
> > As you wrote in the initial e-mail, e-mails are not the primary means
> > of gitlab model, and so, how far it can be stretched and how long it
> > will keep being supported remain to be seen.  Seeing the stretching is
> > rather easy because it can be done now.  But, it is impossible to see
> > how long it will keep being supported in the gitlab model.
>
> Sure this part is just a contemplation, but I think that usage of
> emails was added to gitlab in the first place to keep workflow of
> peoples who got used to mailing lists. In that case I'd expect this to
> be enhanced rather than removed in the future (of course in the end
> this depends on demand or contributions from other peoples. And you are
> a creator of that demand).

I hope it would be the case.  The situation, however, is not
symmetric: building a JavaScript-rich web UI on top of a plain-text
e-mail UI is easier than building a plain-text e-mail UI on top of a
JavaScript-rich web UI.  Consequently, if the plain-text e-mail UI is
ever dropped from the gitlab model owing to its small user base, it
will be more difficult for the small user base to maintain a
third-party plain-text e-mail UI on top of the JavaScript-rich web UI.
In contrast, since a JavaScript-rich web UI will tend to have a larger
user base, and it is easier to build a JavaScript-rich web UI on top
of a plain-text e-mail UI, there should be no problem for those users
who prefer the gitlab model.

> >>  Also, Linux kernel and git has "patchwork" site that essentially
> >> tracks
> >>  open patch-series, versions of patches, comments to them, allows to
> >>  download latest series… It is more advanced than just the mailing
> >>  list as GNU Emacs has.
> >
> > Yes, as you pointed out in the initial e-mail, a mailing list itself
> > is not enough.  That causes the chore of copying and pasting and the
> > like, which can be automated, especially if Emacs is used.  The
> > perspective that I support is that of heterogeneity.  IMO, the gitlab
> > model is into homogeneity: one uniform system for everything, but that
> > sacrifices flexibility.
>
> I just don't see how could gitlab workflow interfere with that. If
> anything, it helps automating the chore of copying and pasting, because
> now you can get someone's series by a simple `git fetch remote branch`.

The gitlab workflow model definitely does not interfere.  On the
contrary, it adds to the heterogeneity.  The point here is about the
proposal to migrate the Emacs model to the gitlab model, which reduces
the heterogeneity.

--
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Stefan Monnier]

I'm no friend of web interfaces, but I'd welcome a system where we can
receive contributions via merge requests.  Gitlab would be acceptable in
this respect.  I don't have enough experience with it to know how
conveniently it can be used without going through the web interface (I
do know that I was very much unimpressed by the commit-diffs messages it
sends, whose text/plain version is much more ugly than what we currently
have and is not using a correct diff file header format).


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 17 Mar 2019 11:06:53 -0400
> 
> I'm no friend of web interfaces, but I'd welcome a system where we can
> receive contributions via merge requests.  Gitlab would be acceptable in
> this respect.  I don't have enough experience with it to know how
> conveniently it can be used without going through the web interface (I
> do know that I was very much unimpressed by the commit-diffs messages it
> sends, whose text/plain version is much more ugly than what we currently
> have and is not using a correct diff file header format).

So you are saying that wherever you did look, Gitlab didn't impress
you, to say the least, but you still think it's a good idea for us to
welcome it?  Or am I missing something?

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>> I'm no friend of web interfaces, but I'd welcome a system where we can
>> receive contributions via merge requests.  Gitlab would be acceptable in
>> this respect.  I don't have enough experience with it to know how
>> conveniently it can be used without going through the web interface (I
>> do know that I was very much unimpressed by the commit-diffs messages it
>> sends, whose text/plain version is much more ugly than what we currently
>> have and is not using a correct diff file header format).
> So you are saying that wherever you did look, Gitlab didn't impress
> you, to say the least, but you still think it's a good idea for us to
> welcome it?  Or am I missing something?

Not exactly, no: I found the web interface fairly usable (as web
interfaces go).

I haven't investigated how well it can interact by email except for the
commit-diffs where I found that it does offer the functionality but that
those email looked gratuitously subpar for my use (people reading the
HTML-rendering may find them nice, OTOH).


        Stefan

Re: [RFE] Migration to gitlab

[Alex]

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

> I'm no friend of web interfaces, but I'd welcome a system where we can
> receive contributions via merge requests.  Gitlab would be acceptable in
> this respect.  I don't have enough experience with it to know how
> conveniently it can be used without going through the web interface (I
> do know that I was very much unimpressed by the commit-diffs messages it
> sends, whose text/plain version is much more ugly than what we currently
> have and is not using a correct diff file header format).
>
>
>         Stefan

What about creating an issue describing the current limitations and
unanswered questions holding back a potential Emacs migration to Gitlab
like KDE[1] and GHC[2] have done at
https://gitlab.com/gitlab-org/gitlab-ce/issues?


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/53206

[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Alex <agrambot@gmail.com> writes:

> What about creating an issue describing the current limitations and
> unanswered questions holding back a potential Emacs migration to Gitlab
> like KDE[1] and GHC[2] have done at
> https://gitlab.com/gitlab-org/gitlab-ce/issues?

I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/60684

It still needs a lot of content, and I've asked collaboration from
GitLab's Director of Community Relations for collaboration.

But anyone here is welcome to comment on that issue, or reply on this
email, and I'll add it to the issue description. I hope to find some
time tonight to read through the thread again and add more to the issue
myself.


-- Toon

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

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 18.04.2019 11:27, Toon Claes wrote:

>> What about creating an issue describing the current limitations and
>> unanswered questions holding back a potential Emacs migration to Gitlab
>> like KDE[1] and GHC[2] have done at
>> https://gitlab.com/gitlab-org/gitlab-ce/issues?
> 
> I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/60684

I fear it's a bit premature, considering we've not worked out the 
minimum requirements between ourselves yet, and Eli has not approved 
even minimal steps toward moving to GitLab.

And "email workflow still should be possible" sounds fairly vague to me.

> It still needs a lot of content, and I've asked collaboration from
> GitLab's Director of Community Relations for collaboration.

Asking somebody from "outside" to read through our mailing list threads 
and make their own conclusions might be asking for trouble. :-)

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> I fear it's a bit premature, considering we've not worked out the
> minimum requirements between ourselves yet, and Eli has not approved
> even minimal steps toward moving to GitLab.

I know Eli didn't approve. This issue is an exploration of the features
required. I totally respect Eli's opinion, and I'm happy he has a
critical look at it.

> Asking somebody from "outside" to read through our mailing list
> threads and make their own conclusions might be asking for
> trouble. :-)

I totally agree, so I spent my evening digging through this whole thread
again. I've updated the issue at
https://gitlab.com/gitlab-org/gitlab-ce/issues/60684

Let me also include the full body of it below, making it easier for
people to comment on it.

One more thing, I'm working at GitLab, so I might sound biased
here. Sorry about that, but I'm a heavy Emacs user too and I'm
passionate about both projects.


-- Toon

====================

[discussion](https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html)
on the emacs-devel mailing list was started to propose migrating the
development process to GitLab. This issue summarizes what would be
required to make that happen. A full migration might never happen, but
a GitLab workflow might be added to the existing mailing list
workflow. There is no decision made whether a migration to GitLab will
ever happen, this is just an exploration of the required and available
features.

This issue only focuses on GitLab, although there might be other
contestants like SourceHut:
https://lists.gnu.org/r/guile-devel/2019-01/msg00027.html

### Motivation

It would be nice if the Emacs community could attract more people to
the source code of Emacs itself. There are a lot of loose packages
created, which could belong to Emacs core. But Emacs development
workflow is "less modern" and that makes it harder for first-time
contributors to submit patches to Emacs core. Using a "more modern"
workflow, which GitLab provides, would lower the threshold for people
getting started.

### Requirements

#### Email workflow

Many people, including the main maintainers of Emacs, prefer a
mail-driven workflow. So however _first-timers_ contribute code, it
has to be compatible with the current mail workflow.

**Current state**

Users can configure their notification settings to get emails for
every issue create/comment addedd/merge request submitted to
GitLab. GitLab supports reply by email, so responses can be send back
directly from the MUA.

#### Submitting patches by email

Sending patches through email, and especially multiple versions of
changes, can be cumbersome. _first-timers_ should be able to submit
their changes to a Merge Request, and the system should be
automatically send out patch mails to a mailing list.

**Current state**

There is no need to squash your commits together to submit them to
GitLab. Because GitLab deals with branches, not with individual
commits.

It is possible to email patches to create a Merge Request:
https://docs.gitlab.com/ee/user/project/merge_requests/#adding-patches-when-creating-a-merge-request-via-e-mail

- [ ] GitLab does not support mailing a new version of the same
      patches

#### Reviewing patches by email

When patches are sent through email, it's easy to reply to them and
inline the comments at the lines the comments apply.

**Current state**

- [ ] GitLab does not support inline comments by email.

#### Merge request creation

It would be preferred if it's not needed to visit the Web UI to create
a Merge Request. Doing everything from the command line is preferred.

**Current state**

It is possible to create a Merge Request upon submit. See the push
options in the GitLab Docs:

https://docs.gitlab.com/ce/user/project/merge_requests/#git-push-options
 
#### Code should be companioned by documentation

Code submission should include documentation.

**Current state**

This is hard to automate, most projects on GitLab or GitHub address
this issue by having a template for Merge Request (or Pull
Requests). It should make contributors aware of ever step they need to
take make the contribution complete.

#### Formatting code commits

Commits should follow a certain formatting.

**Current state**

https://danger.systems/ is a tool often used for this. And it
integrates with GitLab. Although there is still an issue to use Danger
with forks:

- [ ] https://gitlab.com/gitlab-org/gitlab-ce/issues/49134

#### Diff mailing list

At the moment Emacs has a mailing list which generates an email for
every change that is submitted to the git repo. See
https://lists.gnu.org/archive/html/emacs-diffs

#### Traceability of Merge Requests

It should be _hard_ to have Merge Requests vanish and become lost in
history.

**Current state**

On GitLab Merge Requests are normally never deleted. It's very easy to
see which Merge Requests aren't merged yet. You can sort them by date
etc.

#### Continuous integration

Having tests run automatically and make it easy for _first-timers_ to
see the results would mimize the hassle to run automatic checks.

**Current state**

This is a core feature of GitLab. https://emba.gnu.org is already set
up, and tests are running. So this is 90% done. There recently has
been some instabilities with the results and these should be
resolved, see:
https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg00968.html

#### Closely integrated bugtracker

Emacs development uses git and https://debbugs.gnu.org. These two
aren't closely coupled. Whenever a patch for a bug is submitted, it
requires manual steps to also close the bug report.

Emacs has `M-x` `gnus-read-ephemeral-emacs-bug-group` to fetch a
thread on a bug and allows you to respond to it. Or you can download
messages in `mbox` format.

**Current state**

Using GitLab Issues for bug reports will make it easier to have a
relation between submitted changes and bug reports. There are severals
way to link a Merge Request to an Issue, see:
https://docs.gitlab.com/ce/user/project/issues/closing_issues.html#via-merge-request

In GitLab it's also easy to jump in an ongoing discussion on an
existing issue. It does not require looking the `Message-Id` and
manually adding people to `To:`, just add a comment to the issue, and
an email will end up at everyone involved.

- [ ] Export to mbox/maildir is not yet supported
      https://gitlab.com/gitlab-org/gitlab-ce/issues/19524

#### Spell & grammar checking

The documentation should follow the spelling and grammar rules
(e.g. two spaces between sentences).

**Current state**

With a little bit of configuration this is something CI can do. Well
not completely, but it can help. Manually proofreading still would be
required, with any system used.

#### Branch rules

In the workflow it matter to which branch changes are submitted to.

**Current state**

GitLab can have protected branches, and it can enforce some
limitations on those branches. But it still might require checking by
a human whether things are pushed to the correct branch.

#### Copyright assignments

Emacs requires legal paperwork for _larger_ contributions. Having a
built-in method to check if the contributor did take all the legal
actions to contribute can improve the contribution process. But it's a
hard problem, cause privacy has to be ensured.

**Current state**

Only users that are member of the project on GitLab would be allowed
to push branches to the canonical repository. Users who don't have
access can fork the project and submit their branch to that project
and create Merge Request to the canonical repo from their
project. It's a wide-adopted workflow on GitHub, GitLab, BitBucket,
etc.

#### Licensing

The system used has to be Free software.

**Current state**

GitLab CE is published under MIT/Expat license. It's not one of the
preferred licenses, but as far as I know, it's acceptable. Although
RMS did not agree
https://lists.gnu.org/r/emacs-devel/2019-03/msg00594.html, but that
applies to gitlab.com, I'm not sure that also would be true if a
GitLab installation was self-managed on FSF infra.

Also all the frontend Javascript code is free. Although it does not
yet properly report it's licenses to work with LibreJS:

- [ ] https://gitlab.com/gitlab-org/gitlab-ce/issues/15621

#### Integration with savannah

Emacs contributors have their account, SSH key, user rights configured
in https://savannah.gnu.org/. It would be great if the new system
would not require the creation of new accounts and access
rules. Keeping both systems in sync manually is destined to go wrong
at some point.

**Current state**

- [ ] Maybe integration with LDAP or SAML?

#### Integration with debbugs

It's easy to migrate the git repo, but the current database of bug
reports at https://debbugs.gnu.org also should be migrated.

**Current state**

- [ ] Would it be possible to export from debbugs to a CSV format the
      GitLab understands?
      https://docs.gitlab.com/ce/user/project/issues/csv_import.html

#### Emacs frontend for bug tracker

Emacs has a package for debbugs. This is a frontend that can be used
to find/create/update bugs on debbugs.gnu.org.

**Current state**

- [ ] Although GitLab has an API, there is no client for Emacs that
      works with it.
      
#### Bug reporting

Emacs has `M-x` `report-emacs-bug`. It's an awesome feature, but it's
fairly simple and just helps the user to format an email. From then it
uses the system configuration to send the email to the correct
address.

**Current state**

GitLab has a feature to Create Issue by Email, see:
https://docs.gitlab.com/ce/user/project/issues/create_new_issue.html#new-issue-via-email

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

Re: [RFE] Migration to gitlab

[Alex Gramiak]

Toon Claes <toon@iotcl.com> writes:
 
> #### Code should be companioned by documentation
>
> Code submission should include documentation.
>
> **Current state**
>
> This is hard to automate, most projects on GitLab or GitHub address
> this issue by having a template for Merge Request (or Pull
> Requests). It should make contributors aware of ever step they need to
> take make the contribution complete.

Is there an API to get the template for MRs or issues? If so, then Emacs
could use it in report-emacs-bug (or a more general report-emacs-issue)
and a new emacs-create-merge-request.

> **Current state**
>
> - [ ] Although GitLab has an API, there is no client for Emacs that
>       works with it.

https://github.com/magit/ghub (despite the name, it supports Gitlab and
other "forges") should be mentioned in this discussion, though it's not
currently in ELPA.

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Alex Gramiak <agrambot@gmail.com> writes:

> Is there an API to get the template for MRs or issues? If so, then Emacs
> could use it in report-emacs-bug (or a more general report-emacs-issue)
> and a new emacs-create-merge-request.

You can definitely create MRs or issues through the API. I'm not sure
about getting the template, but I don't see much added value to have
this feature cause you can put the template in emacs itself.

>
>> **Current state**
>>
>> - [ ] Although GitLab has an API, there is no client for Emacs that
>>       works with it.
>
> https://github.com/magit/ghub (despite the name, it supports Gitlab and
> other "forges") should be mentioned in this discussion, though it's not
> currently in ELPA.

Magit is a awesome package, and recent the support for "forges" is
great, although not yet very mature. But I usually don't see people here
talk about magit, they tend to use the built-in vc-git instead. So I'm
not sure we can rely on magit or vc-git should get also support for
forges...


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Alex Gramiak]

Toon Claes <toon@iotcl.com> writes:

> Alex Gramiak <agrambot@gmail.com> writes:
>
>> Is there an API to get the template for MRs or issues? If so, then Emacs
>> could use it in report-emacs-bug (or a more general report-emacs-issue)
>> and a new emacs-create-merge-request.
>
> You can definitely create MRs or issues through the API. I'm not sure
> about getting the template, but I don't see much added value to have
> this feature cause you can put the template in emacs itself.

Getting the template would allow for avoiding duplication between the
Emacs side and the Gitlab side, no? In general, it would allow for
3rd-party tools to provide a better (more complete/equivalent)
experience for creating Gitlab issues/MRs.

>> https://github.com/magit/ghub (despite the name, it supports Gitlab and
>> other "forges") should be mentioned in this discussion, though it's not
>> currently in ELPA.
>
> Magit is a awesome package, and recent the support for "forges" is
> great, although not yet very mature. But I usually don't see people here
> talk about magit, they tend to use the built-in vc-git instead. So I'm
> not sure we can rely on magit or vc-git should get also support for
> forges...

I agree that it shouldn't depend on Magit, but ghub at least doesn't
depend on it. It's https://github.com/magit/forge that depends on Magit.

I don't know enough about the Gitlab API to know whether it's worth it
to leverage ghub (and get it copyright-assigned and into ELPA) rather
than to roll our own in a hypothetical gitlab.el.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 24.04.2019 0:08, Toon Claes wrote:
> I totally agree, so I spent my evening digging through this whole thread
> again. I've updated the issue at
> https://gitlab.com/gitlab-org/gitlab-ce/issues/60684

Thank you, the list seems accurate to me.

One phrase stood out weirdly: "Doing everything from the command line is 
preferred." Maybe you'd want to rephrase it, just to give a different 
impression: it's not like we all strongly prefer doing everything from 
the command line (or from inside Emacs), but there are valued 
contributors who do, so we want this workflow to be supported. Or one of 
them, at least (command line or an Emacs package that talks to an API, I 
guess).

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Gcc-Self: nnimap+soverin:Sent
> Date: Tue, 23 Apr 2019 23:08:17 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Alex <agrambot@gmail.com>,
> 	emacs-devel@gnu.org
> 
> > I fear it's a bit premature, considering we've not worked out the
> > minimum requirements between ourselves yet, and Eli has not approved
> > even minimal steps toward moving to GitLab.
> 
> I know Eli didn't approve.

I didn't "didn't approve" "even the minimal steps", that's a gross
misunderstanding of what I wrote.

It is a bit hard to summarize all I said in a few sentences, but if I
have to, it's that I don't yet see a clear overall picture of the
workflow (or workflows, if there will be a few) enough to make up my
mind about the proposed changes.  I don't even understand what
concrete changes are being proposed.  Beyond my relative lack of
familiarity with Gitlab, it provides a large number of features, and
it is not yet clear to me which ones are included in the proposal.  It
might make sense to produce a list of typical tasks and their proposed
alternatives using Gitlab.

In the referenced discussion, I tried (and I guess failed, given the
above "summary") to word my messages not as rejection, but as a
critical assessment of the issues raised by others, because IMO many
of the issues were described in exaggerated form, and the proposed
solutions were described in an optimistic, even simplistic, way that
disregarded important factors and issues in Emacs development and
maintenance that I and others have to deal with every day.  IOW, my
intent was to try to balance the picture, not to reject the proposals.

> https://gitlab.com/gitlab-org/gitlab-ce/issues/60684

Thanks.  I think it's a good idea to maintain a list of issues that we
need to address, and this is a good start.

(A naïve question: there's no "emacs" in the URL, so how does this
issue relate to the project?  And what do "org" and "ce" signify in
this context?)

Allow me now to provide some comments on this.  They are my personal
views at this point, not the project's position.  (They might become
the project position if enough active developers agree with what I
say.)  And please forgive any inaccurate/naïve/silly things I write
due to lack of familiarity with Gitlab.

I intentionally limit myself to only the few major issues, for now; I
think the details should be addressed only after the main issues are
resolved and/or decided.

My main problem with Gitlab is that AFAIU it requires to do most of
the work from a Web browser outside Emacs (I believe EWW is not up to
this job, right?).  I don't like that, mainly because text editing
facilities of a browser are vastly inferior to what I'm used to expect
from Emacs.  Discussing a bug report or a patch in a browser is thus
inefficient and quite frustrating, especially when advanced text
editing and processing is needed.  A browser also takes me a step
further from the source code (you don't suggest that I use File->Open
of the browser to browse the code, right?).  So I think having
efficient integration with Emacs is very important for making the
migration attractive, at least to me.

The second major issue is with bug reports.  This is mentioned towards
the end of the issue, but it is IME much more important than merge
requests, because currently most of the traffic on the bug tracker is
bug reports, not patches.  Efficient handling of the reported issues
is therefore much more important for me than handling of patches, and
I didn't get the impression there's a lot Gitlab can offer in that
direction.  I'd be happy to be mistaken, but if not, IMO we must
provide efficient tools for dealing with bugs, including pinging
assignees after predefined period of time, reassignment requests after
a predefined number of pings, efficient search of bug database for
related issues, a good tagging system for quickly finding related
issues, etc.

Next, it is not clear to me how will this affect my Git workflows.
Before I push a changeset, I like to build Emacs on my system, perhaps
run Emacs under a debugger and look around at relevant variables, run
some tests that I think are relevant, etc.  It sounds like with Gitlab
all that must be done remotely, on some other machine?  And if I want
it on my machine, I will need to checkout a non-master branch and
build it?  That would be inconvenient, to say the least.  One of the
main advantages of a dVCS is that you can do so many things locally,
even when your network connection is down.

Last, but not least: the email interface.  First, please don't
under-estimate its importance.  For people who are involved in several
projects beside Emacs, and cannot afford sitting all day long staring
at the Gitlab UI in the browser, email is important because it doesn't
require polling, it brings the stuff pretty much into one's face.  But
it must be done efficiently.  And here my admittedly limited
experience with Gitlab is abysmally bad: the one project that migrated
to Gitlab basically flooded my inbox with unimportant notifications
like assigning and reassigning issues, changing the issue's severity,
and other similar litter.  I tried to configure the notifications, but
failed to do so (perhaps due to insufficient permissions?), and the
only thing that worked was to disable them altogether.  I think the
email interface must be very good, flexible, and powerful, if we want
to encourage migration.

And one more thing: Emacs is I think special in how we work as a
team.  Most of the people who respond to bug report and review patches
have write access to the repository, and many of them are trusted to
push changes without approval.  It sounds like Gitlab has a very
different team organization in mind, but maybe I'm mistaken.

I think this is enough for now.  Thanks for listening.

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Sorry it took me so long to reply, but we've had some family issues.

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't "didn't approve" "even the minimal steps", that's a gross
> misunderstanding of what I wrote.

I know, and I also didn't want to make it sound like that.

> It is a bit hard to summarize all I said in a few sentences, but if I
> have to, it's that I don't yet see a clear overall picture of the
> workflow (or workflows, if there will be a few) enough to make up my
> mind about the proposed changes.

That's a good point. Some people here already know how the workflow on
GitHub happens, but I understand not everyone is familiar with it.

Let try to explain the contribution process on
GitHub/GitLab/BitBucket/etc. briefly.

A contributor wants submit a change. They generally don't have access to
push changes to the canonical git repo, so on the git hosting provider
they create a "fork", which is basically a ~git clone~ on the remote
server, but _their_ fork, so they can push code to it.

A feature branch is created for the change, and commits are pushed
there. Then a Pull Request or Merge Request to the canonical repo is
created, from their feature branch to e.g. master on emacs. This
Pull/Merge Request generates a page (dynamically) with the diff between
the two branches, similar to the patch they would normally send by
email.

The maintainers of the canonical repo can then, using the web UI,
comment on lines of code, and will ask the contributor to address those
comments. The contributor only has to push the changes to the feature
branch, and the PR/MR page updates the diff automatically. The
maintainers can review again and this can repeat as often as
needed. When the maintainers approve, they click a button, and the
changes get applied to the target branch, e.g. master.

On the PR/MR page you generally also have other information. The author
should fill in a description, explaining the changes. And based on the
settings, a template of checkboxes (in markdown, but similar to org-mode
checkboxes) will be inserted. The maintainers expect from the
contributor to have done the task and check the box if they did.

Also shows the PR/MR page the CI status. So you can directly see if the
automated test suite passed with the changes applied.

> I don't even understand what concrete changes are being proposed.
> Beyond my relative lack of familiarity with Gitlab, it provides a
> large number of features, and it is not yet clear to me which ones are
> included in the proposal.  It might make sense to produce a list of
> typical tasks and their proposed alternatives using Gitlab.

In short:

- forking repos so contributors can push code
- creating Pull/Merge Requests
- inline code review
- automated test results

> In the referenced discussion, I tried (and I guess failed, given the
> above "summary") to word my messages not as rejection, but as a
> critical assessment of the issues raised by others

That's also how I saw it. By introducing a GH/GL/BB/etc workflow we want
to make the process less painful of irregular contributors, but of
course the maintainers should not suffer from this. So my goal here is
also to be constructive and see whether we can mix that in. 

> because IMO many of the issues were described in exaggerated form

Exaggerated in which sense? I know it's trivial to you to send replies
and patches to debbugs, but to people used to the workflow described
above, it's not.

> and the proposed solutions were described in an optimistic, even
> simplistic, way that disregarded important factors and issues in Emacs
> development and maintenance that I and others have to deal with every
> day.  IOW, my intent was to try to balance the picture, not to reject
> the proposals.

I think we're on the same page here.

>> https://gitlab.com/gitlab-org/gitlab-ce/issues/60684
>
> Thanks.  I think it's a good idea to maintain a list of issues that we
> need to address, and this is a good start.
>
> (A naïve question: there's no "emacs" in the URL, so how does this
> issue relate to the project?  And what do "org" and "ce" signify in
> this context?)

I've created this issue on the project site where GitLab-CE is
maintained. So the goal is to make changes (if needed) to GitLab, to
make it possible to use GitLab for emacs development, if we ever manage
to succeed in that. 'gitlab-org' is the group, all software projects
made by the GitLab company are in that group. 'gitlab-ce' is the name of
the project. The CE stands for Community Edition, basically it's the
Free (as is Freedom) edition of GitLab. It does not contain any
proprietary code and is fully licensed under the MIT/Expat license.

> Allow me now to provide some comments on this.  They are my personal
> views at this point, not the project's position.  (They might become
> the project position if enough active developers agree with what I
> say.)  And please forgive any inaccurate/naïve/silly things I write
> due to lack of familiarity with Gitlab.
>
> I intentionally limit myself to only the few major issues, for now; I
> think the details should be addressed only after the main issues are
> resolved and/or decided.
>
> My main problem with Gitlab is that AFAIU it requires to do most of
> the work from a Web browser outside Emacs (I believe EWW is not up to
> this job, right?).

GitLab relies on javascript a lot, and EWW doesn't really cope well with
that.

> I don't like that, mainly because text editing facilities of a browser
> are vastly inferior to what I'm used to expect from Emacs.

I understand. That's why I want to figure out whether we can add changes
to GitLab, so (almost) everything also can be done outside the
webbrowser, and from emacs. Or maybe build something like the debbugs
package for emacs.

Side note: I sometimes enjoy using the browser plugin
https://github.com/GhostText/GhostText to edit textboxes, in Emacs. But
requires whiching between browser and Emacs, which isn't ideal.

> Discussing a bug report or a patch in a browser is thus inefficient
> and quite frustrating, especially when advanced text editing and
> processing is needed.  A browser also takes me a step further from the
> source code (you don't suggest that I use File->Open of the browser to
> browse the code, right?).

Well, mention you mention a commit hash in your comments, the hash
becomes clickable, taking you directly to the change. You can also use
hyperlinks to pieces of code, etc. I know it's weird to do that in the
browser, but many people grown accustomed to that. But not everyone will
like that.

> So I think having efficient integration with Emacs is very important
> for making the migration attractive, at least to me.

Many people will agree, I think.

> The second major issue is with bug reports.  This is mentioned towards
> the end of the issue, but it is IME much more important than merge
> requests, because currently most of the traffic on the bug tracker is
> bug reports, not patches.  Efficient handling of the reported issues
> is therefore much more important for me than handling of patches, and
> I didn't get the impression there's a lot Gitlab can offer in that
> direction.  I'd be happy to be mistaken, but if not, IMO we must
> provide efficient tools for dealing with bugs, including pinging
> assignees after predefined period of time, reassignment requests after
> a predefined number of pings, efficient search of bug database for
> related issues, a good tagging system for quickly finding related
> issues, etc.

Probably the most complicated about the current bug tracker, at least
from irregular contributor's POV, is interacting to a existing bug:
Where do I send the email to? Who do I CC? How do I set In-Reply-To?

I think GitLab can help a lot here. Contributors can type a reply
directly using the web UI. When a reply is made, GitLab also sends out
that by email to everyone subscribed. When you have interacted with the
ticket, you are subscribed, or you can subscribe manually, or you can
configure to be subscribed to everything.

On debbugs, I also always forget how to use the control server
commands. GitLab fixes that by showing buttons for actions like
close/reopen/label/assign...

And the great thing, I think there is nothing(?) you can do on the web
UI, that you cannot do by email. Because GitLab has similar control
commands, called Quick Actions:
https://docs.gitlab.com/ce/user/project/quick_actions.html

> Next, it is not clear to me how will this affect my Git workflows.
> Before I push a changeset, I like to build Emacs on my system, perhaps
> run Emacs under a debugger and look around at relevant variables, run
> some tests that I think are relevant, etc.  It sounds like with Gitlab
> all that must be done remotely, on some other machine?  And if I want
> it on my machine, I will need to checkout a non-master branch and
> build it?  That would be inconvenient, to say the least.  One of the
> main advantages of a dVCS is that you can do so many things locally,
> even when your network connection is down.

This probably still a shortcoming in GitLab. You are right, to get the
code locally, you need to fetch and checkout the feature branch the
contributor created. Unfortunately, GitLab does not send out an email
with patches whenever the author pushes changes to their feature
branch. I will add that to the referred issue on gitlab.com.

But at the moment you can get the diff of a merge request as patch
format, e.g.:
https://emba.gnu.org/emacs/emacs/merge_requests/1.patch

But that also does not help when you don't have an internet connection.

> Last, but not least: the email interface.  First, please don't
> under-estimate its importance.  For people who are involved in several
> projects beside Emacs, and cannot afford sitting all day long staring
> at the Gitlab UI in the browser, email is important because it doesn't
> require polling, it brings the stuff pretty much into one's face.  But
> it must be done efficiently.  And here my admittedly limited
> experience with Gitlab is abysmally bad: the one project that migrated
> to Gitlab basically flooded my inbox with unimportant notifications
> like assigning and reassigning issues, changing the issue's severity,
> and other similar litter.  I tried to configure the notifications, but
> failed to do so (perhaps due to insufficient permissions?), and the
> only thing that worked was to disable them altogether.  I think the
> email interface must be very good, flexible, and powerful, if we want
> to encourage migration.

Yes, I tried to stress the importance of email too. I regret to hear the
email interface of GitLab didn't work for you. I'll have a look whether
I can suggest changes to make the "litter" configurable. But besides
from that, are there any other annoyances you've encountered so far?

I hate to admit it, if email is the top priority, then maybe
https://sourcehut.org/ is a better alternative than GitLab. It is built
with an email/patch flow as first-class citizen. But TBH, I haven't used
it, so I cannot tell more about it and if we consider that, I suggest
someone with more experience on it will drive the possible path to
migration.

> And one more thing: Emacs is I think special in how we work as a
> team.  Most of the people who respond to bug report and review patches
> have write access to the repository, and many of them are trusted to
> push changes without approval.  It sounds like Gitlab has a very
> different team organization in mind, but maybe I'm mistaken.

GitLab shouldn't try to force you in some organisation structure, I
think there are many projects operating in very different ways, GitLab
should support that, and not counter it.

> I think this is enough for now.  Thanks for listening.

Thanks, I appreciate your extensive reply.


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  agrambot@gmail.com,  dgutov@yandex.ru
> Date: Fri, 10 May 2019 11:16:52 +0200
> 
> Sorry it took me so long to reply, but we've had some family issues.

We all have Real Lifes™, no need to apologize about that.

I'm more worried that no one else responded to my description.

> Let try to explain the contribution process on
> GitHub/GitLab/BitBucket/etc. briefly.
> 
> A contributor wants submit a change.

Note how you again start from a change, not from a report of some
issue/bug.  As Emacs is a very old and stable project, most of our
changes fix bugs, not add new features.  Therefore, use cases that
begin with issues are much more important to the workflow and to
assessing the utility of the tools.

> > because IMO many of the issues were described in exaggerated form
> 
> Exaggerated in which sense?

In the sense of representing various aspects of the current flow as
abysmally inadequate, and the proposed solutions as no less than a
panacea.

> > I don't like that, mainly because text editing facilities of a browser
> > are vastly inferior to what I'm used to expect from Emacs.
> 
> I understand. That's why I want to figure out whether we can add changes
> to GitLab, so (almost) everything also can be done outside the
> webbrowser, and from emacs. Or maybe build something like the debbugs
> package for emacs.

Personally, I think an Emacs client is almost a must, if we want to
consider something like GitLab seriously.

> > Discussing a bug report or a patch in a browser is thus inefficient
> > and quite frustrating, especially when advanced text editing and
> > processing is needed.  A browser also takes me a step further from the
> > source code (you don't suggest that I use File->Open of the browser to
> > browse the code, right?).
> 
> Well, mention you mention a commit hash in your comments, the hash
> becomes clickable

I didn't mean the commit itself, I meant Emacs sources in general.  I
frequently need to look up source fragments and definitions of various
macros and structs when I review a patch.  Since the browser have no
idea where the sources are, and is not in general a good tool for
viewing sources of a software project, it is much less helpful here.

> Probably the most complicated about the current bug tracker, at least
> from irregular contributor's POV, is interacting to a existing bug:
> Where do I send the email to? Who do I CC? How do I set In-Reply-To?

In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
the defaults always DTRT.  You don't need to think about any of that.

> On debbugs, I also always forget how to use the control server
> commands.

Having a need to use the control command is rare, so I don't think
this is a serious disadvantage.  Besides, tricky control commands will
give you that with any tool.

> GitLab fixes that by showing buttons for actions like
> close/reopen/label/assign...

There are maybe 2 or 3 people in the Emacs project who use these
actions, so I'm not sure why we should be so interested in them.

> Yes, I tried to stress the importance of email too. I regret to hear the
> email interface of GitLab didn't work for you. I'll have a look whether
> I can suggest changes to make the "litter" configurable. But besides
> from that, are there any other annoyances you've encountered so far?

I don't know.  If the email notifications can be configured to work
reasonably well, and could be responded to by email, that might be
enough to start a more serious evaluation of the workflow.

> > And one more thing: Emacs is I think special in how we work as a
> > team.  Most of the people who respond to bug report and review patches
> > have write access to the repository, and many of them are trusted to
> > push changes without approval.  It sounds like Gitlab has a very
> > different team organization in mind, but maybe I'm mistaken.
> 
> GitLab shouldn't try to force you in some organisation structure

We'll need to explore this more, I think.  It was my impression that
many defaults there were configured for a certain hierarchical
organization of the team, which is not what we have here.

Re: [RFE] Migration to gitlab

[조성빈]

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

Well, I have used both GitLab & Github, and my few cents:
(I may have mixed up Github and Gitlab as I use Github much more than Gitlab; please fix me if I’m wrong)

2019. 5. 10. 오후 6:49, Eli Zaretskii <eliz@gnu.org> 작성:

>> Let try to explain the contribution process on
>> GitHub/GitLab/BitBucket/etc. briefly.
>> 
>> A contributor wants submit a change.
> 
> Note how you again start from a change, not from a report of some
> issue/bug.  As Emacs is a very old and stable project, most of our
> changes fix bugs, not add new features.  Therefore, use cases that
> begin with issues are much more important to the workflow and to
> assessing the utility of the tools.

Any contributor can freely submit a pull request that has the word `Fixes #(Issue number)` and when the pull request is accepted, the issue is automatically closed.

>>> because IMO many of the issues were described in exaggerated form
>> 
>> Exaggerated in which sense?
> 
> In the sense of representing various aspects of the current flow as
> abysmally inadequate, and the proposed solutions as no less than a
> panacea.

Both workflows are inadequate, and overly complicated, but most people will be more familiar to the Gitlab Pull request workflow, and greatly lowers the bar for people who would like to contribute for the first time.

>>> I don't like that, mainly because text editing facilities of a browser
>>> are vastly inferior to what I'm used to expect from Emacs.
>> 
>> I understand. That's why I want to figure out whether we can add changes
>> to GitLab, so (almost) everything also can be done outside the
>> webbrowser, and from emacs. Or maybe build something like the debbugs
>> package for emacs.
> 
> Personally, I think an Emacs client is almost a must, if we want to
> consider something like GitLab seriously.

There are many Emacs clients that tightly integrates with magit; I assume you use magit for managing git repos? 

The best one IMO is the official (magit) one:
Release: https://emacsair.me/2018/12/19/forge-0.1/
Manula: https://magit.vc/manual/forge/
Repo: https://github.com/magit/forge

I’m not sure if commenting on PRs are available; (I don’t use that feature particularly) but I regularly create issues/PRs and push them, fetch them, etc... and notification is also available :-)

It works with Github and Gitlab, and semi-supports Gitea and other forges.

(The initial setup needs the web UI when using Gitlab though; as the Gitlab API doesn’t support create a token unless Github.)

>>> Discussing a bug report or a patch in a browser is thus inefficient
>>> and quite frustrating, especially when advanced text editing and
>>> processing is needed.  A browser also takes me a step further from the
>>> source code (you don't suggest that I use File->Open of the browser to
>>> browse the code, right?).
>> 
>> Well, mention you mention a commit hash in your comments, the hash
>> becomes clickable
> 
> I didn't mean the commit itself, I meant Emacs sources in general.  I
> frequently need to look up source fragments and definitions of various
> macros and structs when I review a patch.  Since the browser have no
> idea where the sources are, and is not in general a good tool for
> viewing sources of a software project, it is much less helpful here.

With emacs(see magit/forge), this is not an issue anymore! :-)

>> Probably the most complicated about the current bug tracker, at least
>> from irregular contributor's POV, is interacting to a existing bug:
>> Where do I send the email to? Who do I CC? How do I set In-Reply-To?
> 
> In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
> the defaults always DTRT.  You don't need to think about any of that.
> 
>> On debbugs, I also always forget how to use the control server
>> commands.
> 
> Having a need to use the control command is rare, so I don't think
> this is a serious disadvantage.  Besides, tricky control commands will
> give you that with any tool.
> 
>> GitLab fixes that by showing buttons for actions like
>> close/reopen/label/assign...
> 
> There are maybe 2 or 3 people in the Emacs project who use these
> actions, so I'm not sure why we should be so interested in them.
> 
>> Yes, I tried to stress the importance of email too. I regret to hear the
>> email interface of GitLab didn't work for you. I'll have a look whether
>> I can suggest changes to make the "litter" configurable. But besides
>> from that, are there any other annoyances you've encountered so far?
> 
> I don't know.  If the email notifications can be configured to work
> reasonably well, and could be responded to by email, that might be
> enough to start a more serious evaluation of the workflow.

As magit/forge supports viewing notifications about the repo in the magit interface; this is no longer an issue anymore.

>>> And one more thing: Emacs is I think special in how we work as a
>>> team.  Most of the people who respond to bug report and review patches
>>> have write access to the repository, and many of them are trusted to
>>> push changes without approval.  It sounds like Gitlab has a very
>>> different team organization in mind, but maybe I'm mistaken.
>> 
>> GitLab shouldn't try to force you in some organisation structure
> 
> We'll need to explore this more, I think.  It was my impression that
> many defaults there were configured for a certain hierarchical
> organization of the team, which is not what we have here.
> 

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Fri, 10 May 2019 19:37:31 +0900
> Cc: Toon Claes <toon@iotcl.com>, dgutov@yandex.ru, monnier@iro.umontreal.ca,
>  agrambot@gmail.com, emacs-devel@gnu.org
> 
> > Note how you again start from a change, not from a report of some
> > issue/bug.  As Emacs is a very old and stable project, most of our
> > changes fix bugs, not add new features.  Therefore, use cases that
> > begin with issues are much more important to the workflow and to
> > assessing the utility of the tools.
> 
> Any contributor can freely submit a pull request that has the word `Fixes #(Issue number)` and when the pull request is accepted, the issue is automatically closed.

My point was that an absolute majority of Emacs issues don't have a
patch attached.  They describe a problem, and most of the reports
don't even include a detailed analysis of the problem and its root
cause.  A large part of discussing an issue is devoted to
understanding the issue and then finding its cause.  Patches appear
only after all that.

So we must have a good support for a workflow that doesn't include any
pull/merge request at its beginning, maybe even never.

> >> Exaggerated in which sense?
> > 
> > In the sense of representing various aspects of the current flow as
> > abysmally inadequate, and the proposed solutions as no less than a
> > panacea.
> 
> Both workflows are inadequate

Not really relevant to the question and the answer.

> and overly complicated, but most people will be more familiar to the Gitlab Pull request workflow, and greatly lowers the bar for people who would like to contribute for the first time.

Please don't forget that any change should also not unduly _raise_ the
bar for the current core team, to be acceptable.

> > Personally, I think an Emacs client is almost a must, if we want to
> > consider something like GitLab seriously.
> 
> There are many Emacs clients that tightly integrates with magit; I assume you use magit for managing git repos? 
> 
> The best one IMO is the official (magit) one:
> Release: https://emacsair.me/2018/12/19/forge-0.1/
> Manula: https://magit.vc/manual/forge/
> Repo: https://github.com/magit/forge

It sounds like you are advocating the adoption of a system other than
GitLab.  If so, I think we should first decide that GitLab is not good
enough, something I believe we didn't decide yet.

> It works with Github and Gitlab, and semi-supports Gitea and other forges.

If by "it" you mean forge, would you please describe how it would be
used in the Emacs maintenance workflows?  (Having to install magit is
a certain disadvantage, but it isn't by itself enough to make this
alternative unacceptable, IMO.)

Re: [RFE] Migration to gitlab

[조성빈]

2019. 5. 10. 오후 9:21, Eli Zaretskii <eliz@gnu.org> 작성:

>> From: 조성빈 <pcr910303@icloud.com>
>> Date: Fri, 10 May 2019 19:37:31 +0900
>> Cc: Toon Claes <toon@iotcl.com>, dgutov@yandex.ru, monnier@iro.umontreal.ca,
>> agrambot@gmail.com, emacs-devel@gnu.org
>> 
>>> Note how you again start from a change, not from a report of some
>>> issue/bug.  As Emacs is a very old and stable project, most of our
>>> changes fix bugs, not add new features.  Therefore, use cases that
>>> begin with issues are much more important to the workflow and to
>>> assessing the utility of the tools.
>> 
>> Any contributor can freely submit a pull request that has the word `Fixes #(Issue number)` and when the pull request is accepted, the issue is automatically closed.
> 
> My point was that an absolute majority of Emacs issues don't have a
> patch attached.  They describe a problem, and most of the reports
> don't even include a detailed analysis of the problem and its root
> cause.  A large part of discussing an issue is devoted to
> understanding the issue and then finding its cause.  Patches appear
> only after all that.
> 
> So we must have a good support for a workflow that doesn't include any
> pull/merge request at its beginning, maybe even never.

Ah, I didn’t explain it enough. Sorry for that :-(
There is an issue tracker. Anyone can submit issues(bugs) to there.
There is also a Pull Request tracker.
If one (not necessarily the issue opener; usually will be different) has enough authority to commit to the git repo, he/she can just commit to the main repo with a commit message containing (one or multiple) `Fixes #(issue number)` and the issue is automatically closed, with an additional message `Commit (hash number) closed this issue.`
If an external (potential) contributor makes a fix for any issue (no need to be the contributor’s issue) in the issue tracker, but doesn’t have enough authority to commit to the main repo, 
1) he can fork the repo
2) push/commit his changes
3) and make a pull request to the main repo
4) with the pull request message (think as another git commit message) containing (one or multiple) `Fixes #(issue number)` (Optional, there is no need for the pull request to be associated with an issue)

and one that has enough authority can review the pull request (patch) and merge the forked repo, just like merging a branch to another one.
When the pull request is merged, the associated issue is automatically closed.

This is the basic workflow when using GitLab, and everything mentioned in the workflow can be done with the package ‘magit/forge’ I mentioned below.

>>>> Exaggerated in which sense?
>>> 
>>> In the sense of representing various aspects of the current flow as
>>> abysmally inadequate, and the proposed solutions as no less than a
>>> panacea.
>> 
>> Both workflows are inadequate
> 
> Not really relevant to the question and the answer.
> 
>> and overly complicated, but most people will be more familiar to the Gitlab Pull request workflow, and greatly lowers the bar for people who would like to contribute for the first time.
> 
> Please don't forget that any change should also not unduly _raise_ the
> bar for the current core team, to be acceptable.

I’m pretty sure the current workflow using emails can be applied to GitLab; as isn’t it just using standard git features?

>>> Personally, I think an Emacs client is almost a must, if we want to
>>> consider something like GitLab seriously.
>> 
>> There are many Emacs clients that tightly integrates with magit; I assume you use magit for managing git repos? 
>> 
>> The best one IMO is the official (magit) one:
>> Release: https://emacsair.me/2018/12/19/forge-0.1/
>> Manula: https://magit.vc/manual/forge/
>> Repo: https://github.com/magit/forge
> 
> It sounds like you are advocating the adoption of a system other than
> GitLab.  If so, I think we should first decide that GitLab is not good
> enough, something I believe we didn't decide yet.

The magit/forge is a MELPA package that can integrate tightly with Gitlab/Github/etc...
It’s an answer to your question about how to use the GitLab workflow in Emacs.

>> It works with Github and Gitlab, and semi-supports Gitea and other forges.
> 
> If by "it" you mean forge, would you please describe how it would be
> used in the Emacs maintenance workflows?  (Having to install magit is
> a certain disadvantage, but it isn't by itself enough to make this
> alternative unacceptable, IMO.)

Well, magit/forge is a package, which means you (and a hypothetical emacs contributor) can use the GitLab workflow (explained by other people) inside Emacs.

Re: [RFE] Migration to gitlab

[Alex Gramiak]

Eli Zaretskii <eliz@gnu.org> writes:

> My point was that an absolute majority of Emacs issues don't have a
> patch attached.  They describe a problem, and most of the reports
> don't even include a detailed analysis of the problem and its root
> cause.  A large part of discussing an issue is devoted to
> understanding the issue and then finding its cause.  Patches appear
> only after all that.
>
> So we must have a good support for a workflow that doesn't include any
> pull/merge request at its beginning, maybe even never.

Gitlab et al. would provide that, IMO. When there's no PR/MR at the
beginning, the topic is submitted as an "Issue" and given a unique issue
number. However, patches aren't submitted to the issue: rather, a new
PR/MR is created, given a unique MR number, and is linked with the
relevant issue(s). When the PR/MR is merged, any linked issues are
closed.

This means that the discussion gets separated into two parts: the
discussion about the issue/problem (kept in the "Issues" category), and
the discussion about the patch/solution (kept in the "Merge Requests"
category).

Re: [RFE] Migration to gitlab

[Alan Mackenzie]

Hello, Alex.

On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > My point was that an absolute majority of Emacs issues don't have a
> > patch attached.  They describe a problem, and most of the reports
> > don't even include a detailed analysis of the problem and its root
> > cause.  A large part of discussing an issue is devoted to
> > understanding the issue and then finding its cause.  Patches appear
> > only after all that.

> > So we must have a good support for a workflow that doesn't include any
> > pull/merge request at its beginning, maybe even never.

I don't know what "pull/merge request" means.  Does it mean a request by
an outsider for a core contributor to perform a "git pull" operation
from the outsider's computer, the outsider having opened up his machine
to public access to allow this?

> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
> beginning, the topic is submitted as an "Issue" and given a unique issue
> number. However, patches aren't submitted to the issue: rather, a new
> PR/MR is created, given a unique MR number, and is linked with the
> relevant issue(s).

Yuck!  I recently worked with a proprietory system where each bug had
several different numbers, an  issue number, an analysis number, a patch
number, and so on.  It caused extra effort to keep track of bugs, and
was generally horrible.

> When the PR/MR is merged, any linked issues are closed.

You needn't have used the passive voice, there.  What does your sentence
mean?  That when a user merges a PR/MR, gitlab automatically closes the
issue (whether it's finished, or not)?  Or that a user can close an
issue only after somebody has first merged at least one PR/MR?  Or
something else?

What is the point of issues and PR/MRs having distinct identifiers, if
they are so tightly coupled with eachother?

> This means that the discussion gets separated into two parts: the
> discussion about the issue/problem (kept in the "Issues" category), and
> the discussion about the patch/solution (kept in the "Merge Requests"
> category).

This sounds like a Bad Thing to me.  It sounds rather like a workflow
being imposed which imagines that first the bug gets "resolved"
(whatever that means) in discussion, and only then does work start on a
separate "merge request".  The above mentioned proprietory system was
like this.  It didn't lend itself to a natural and efficient way of
working.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [RFE] Migration to gitlab

[조성빈]

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


2019. 5. 11. 오전 11:12, Alan Mackenzie <acm@muc.de> 작성:

> Hello, Alex.
> 
>> On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> My point was that an absolute majority of Emacs issues don't have a
>>> patch attached.  They describe a problem, and most of the reports
>>> don't even include a detailed analysis of the problem and its root
>>> cause.  A large part of discussing an issue is devoted to
>>> understanding the issue and then finding its cause.  Patches appear
>>> only after all that.
> 
>>> So we must have a good support for a workflow that doesn't include any
>>> pull/merge request at its beginning, maybe even never.
> 
> I don't know what "pull/merge request" means.  Does it mean a request by
> an outsider for a core contributor to perform a "git pull" operation
> from the outsider's computer, the outsider having opened up his machine
> to public access to allow this?

An outsider that is not a core contributor cannot make a new branch (as he/she doesn’t have enough authorization).
So the outsider can ‘fork’ the repo, to make an exact clone of it, push his/her changes(commits) to GitLab, and make a merge request. The pull/merge request is a request the core contributor to ‘pull’ the changes of the forked repo and ‘merge’ it just as if the forked repo is just another branch.
This can be done by just clicking a button to merge(in the web UI).
Merging is also available in the command line; see https://gist.github.com/adam-p/15413fabef6cffecd897 ; but I’ve never seen anyone merging PRs like that in real life.

>> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
>> beginning, the topic is submitted as an "Issue" and given a unique issue
>> number. However, patches aren't submitted to the issue: rather, a new
>> PR/MR is created, given a unique MR number, and is linked with the
>> relevant issue(s).
> 
> Yuck!  I recently worked with a proprietory system where each bug had
> several different numbers, an  issue number, an analysis number, a patch
> number, and so on.  It caused extra effort to keep track of bugs, and
> was generally horrible.

IIRC Gitlab uses one number for all ‘topic’s, but there are two types of topics(e.g. issue and PR). If you were annoyed that there are few types of different numbers, (e.g. Bug#71 and Analysis#71), GitLab is not the case.
There is only one #71 and it’s an issue or PR.

>> When the PR/MR is merged, any linked issues are closed.
> 
> You needn't have used the passive voice, there.  What does your sentence
> mean?  That when a user merges a PR/MR, gitlab automatically closes the
> issue (whether it's finished, or not)?  Or that a user can close an
> issue only after somebody has first merged at least one PR/MR?  Or
> something else?

When the core contributor decides that the PR is done and merges it to the main repo, GitLab automatically closes the issue. (If the PR was found to be an incomplete solution, the issue can be re-opened.)

> What is the point of issues and PR/MRs having distinct identifiers, if
> they are so tightly coupled with eachother?

As I mentioned before, they don’t have ‘distinct’ identifiers; any issue/PR can cross-reference other issue/PR with the number.

If you’re saying what’s the point of having two types of topics(issues and PRs), it’s that PRs are primarily a way to put code, while issues are primarily a way to report bugs, feature requests.

If an core contributor fixed an issue, one doesn’t have to create a PR(as he/she already has commit; he/she can just mention the issue number in the commit message and it will be automatically closed.

>> This means that the discussion gets separated into two parts: the
>> discussion about the issue/problem (kept in the "Issues" category), and
>> the discussion about the patch/solution (kept in the "Merge Requests"
>> category).
> 
> This sounds like a Bad Thing to me.  It sounds rather like a workflow
> being imposed which imagines that first the bug gets "resolved"
> (whatever that means) in discussion, and only then does work start on a
> separate "merge request".  The above mentioned proprietory system was
> like this.  It didn't lend itself to a natural and efficient way of
> working.

No, one can interact with the bug while writing a patch and making a PR (or a commit). You can make a PR and continue to modify the PR (as the bug gets resolved?) until it becomes merged.

> -- 
> Alan Mackenzie (Nuremberg, Germany).
> 

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Sat, 11 May 2019 12:47:27 +0900
> Cc: Alex Gramiak <agrambot@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org, toon@iotcl.com, monnier@iro.umontreal.ca,
>  dgutov@yandex.ru
> 
> So the outsider can ‘fork’ the repo, to make an exact clone of it, push his/her changes(commits) to GitLab,
> and make a merge request. The pull/merge request is a request the core contributor to ‘pull’ the changes of
> the forked repo and ‘merge’ it just as if the forked repo is just another branch.
> This can be done by just clicking a button to merge(in the web UI).

Does "clicking a button" take care of various minor details I
frequently need to do when applying patches from random contributors,
such as fixing the log messages (or providing them in the first
place), adding a reference to the bug/issue, adding the
Copyright-paperwork-exempt tag, etc.?

> When the core contributor decides that the PR is done and merges it to the main repo, GitLab automatically
> closes the issue. (If the PR was found to be an incomplete solution, the issue can be re-opened.)

We currently have the opposite situation: pushing a fix doesn't
automatically close the issue.  Both are bad as defaults, because IME
what needs to be done is split roughly 50%.  So a much better UI would
be to force the user to check a box when "clicking the merge button".

> If you’re saying what’s the point of having two types of topics(issues and PRs), it’s that PRs are primarily a
> way to put code, while issues are primarily a way to report bugs, feature requests.

There's no such distinction in practice, it is a purely artificial
thing.  There should be only one category, whether there is or isn't a
PR.  But I don't think this aspect should be of any significant
importance, it's just a fluke to get used to.

Re: [RFE] Migration to gitlab

[조성빈]

2019. 5. 11. 오후 4:01, Eli Zaretskii <eliz@gnu.org> 작성:

>> From: 조성빈 <pcr910303@icloud.com>
>> Date: Sat, 11 May 2019 12:47:27 +0900
>> Cc: Alex Gramiak <agrambot@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>> emacs-devel@gnu.org, toon@iotcl.com, monnier@iro.umontreal.ca,
>> dgutov@yandex.ru
>> 
>> So the outsider can ‘fork’ the repo, to make an exact clone of it, push his/her changes(commits) to GitLab,
>> and make a merge request. The pull/merge request is a request the core contributor to ‘pull’ the changes of
>> the forked repo and ‘merge’ it just as if the forked repo is just another branch.
>> This can be done by just clicking a button to merge(in the web UI).
> 
> Does "clicking a button" take care of various minor details I
> frequently need to do when applying patches from random contributors,
> such as fixing the log messages (or providing them in the first
> place), adding a reference to the bug/issue, adding the
> Copyright-paperwork-exempt tag, etc.?

I’m not sure about what ‘log messages’ mean.
If you’re saying commit messages, you can view them and ask the contributors to fix the messages, rebase the commits, and force-push them. You can merge them afterwards.
And yes, GitLab adds the reference to the issue, which commit or PR resolves this issue.
About adding the copyright/paperworks, there isn’t a default setting, but you can have a bot to do that. I’ve never used one myself, so I’m not sure, but I’ve seen lots of projects that use bots to get paperwork, etc... 

>> When the core contributor decides that the PR is done and merges it to the main repo, GitLab automatically
>> closes the issue. (If the PR was found to be an incomplete solution, the issue can be re-opened.)
> 
> We currently have the opposite situation: pushing a fix doesn't
> automatically close the issue.  Both are bad as defaults, because IME
> what needs to be done is split roughly 50%.  So a much better UI would
> be to force the user to check a box when "clicking the merge button".

Mentioning (and closing) issues in commit messages/PR messages are completely optional; If you feel that this commit or PR fix shouldn’t close the issue, you just don’t have to mention the issue, and ask the issue reporter check if the commit/PR fixes the particular issue, etc...

>> If you’re saying what’s the point of having two types of topics(issues and PRs), it’s that PRs are primarily a
>> way to put code, while issues are primarily a way to report bugs, feature requests.
> 
> There's no such distinction in practice, it is a purely artificial
> thing.  There should be only one category, whether there is or isn't a
> PR.  But I don't think this aspect should be of any significant
> importance, it's just a fluke to get used to.

Think as a PR a commit that needs authorization; We don’t mix commits with issues :-)

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Sat, 11 May 2019 16:38:30 +0900
> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  acm@muc.de, toon@iotcl.com, agrambot@gmail.com
> 
> > Does "clicking a button" take care of various minor details I
> > frequently need to do when applying patches from random contributors,
> > such as fixing the log messages (or providing them in the first
> > place), adding a reference to the bug/issue, adding the
> > Copyright-paperwork-exempt tag, etc.?
> 
> I’m not sure about what ‘log messages’ mean.

Commit log messages.

> If you’re saying commit messages, you can view them and ask the contributors to fix the messages, rebase the commits, and force-push them. You can merge them afterwards.

Asking the contributors to fix the log messages works only up to some
not very far limit.  Quite frequently, IME, the 2nd, the 3rd, and
sometimes the 4th attempt are still not what I'd like to see, whether
due to misunderstanding or something else.  At which point I usually
give up and fix the rest myself, so as not to discourage the
contributor the next time he/she wants to contribute.

Force-push is normally not an option, as our repository disallows
that, to avoid someone's mistake corrupting the repository or losing
data.

So there should be an easy way of accepting a PR/MR where I can
augment the log message in the process.  Because once the commit is
pushed, whatever deficiencies there were in the log message are carved
in stone forever.

> And yes, GitLab adds the reference to the issue, which commit or PR resolves this issue.

What if the issue is not yet resolved, like when we commit a change
that fixes only part of the issue, or is only tangentially related to
it?  We cannot yet close the issue, but a reference to it should be in
the commit log.

> About adding the copyright/paperworks, there isn’t a default setting, but you can have a bot to do that. I’ve never used one myself, so I’m not sure, but I’ve seen lots of projects that use bots to get paperwork, etc... 

How can a bot do that, when a commit log message is immutable once the
commit is pushed?

Anyway, the above are all bread and butter of core developers' work
when we accept contributions.  If we are to migrate to another
platform, that platform should help us in these areas, or at least not
make them less convenient.  Support for those aspects should be part
of evaluating the alternatives, IMO.

> > We currently have the opposite situation: pushing a fix doesn't
> > automatically close the issue.  Both are bad as defaults, because IME
> > what needs to be done is split roughly 50%.  So a much better UI would
> > be to force the user to check a box when "clicking the merge button".
> 
> Mentioning (and closing) issues in commit messages/PR messages are completely optional; If you feel that this commit or PR fix shouldn’t close the issue, you just don’t have to mention the issue, and ask the issue reporter check if the commit/PR fixes the particular issue, etc...

See above: sometimes the issue _should_ be mentioned, even though it
isn't yet closed by a commit.

> We don’t mix commits with issues :-)

I think we do, and we should.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 11.05.2019 13:02, Eli Zaretskii wrote:

> Asking the contributors to fix the log messages works only up to some
> not very far limit.  Quite frequently, IME, the 2nd, the 3rd, and
> sometimes the 4th attempt are still not what I'd like to see, whether
> due to misunderstanding or something else.  At which point I usually
> give up and fix the rest myself, so as not to discourage the
> contributor the next time he/she wants to contribute.

Same here.

> So there should be an easy way of accepting a PR/MR where I can
> augment the log message in the process.  Because once the commit is
> pushed, whatever deficiencies there were in the log message are carved
> in stone forever.

There are basically two options:

If the MR only has a few commits (or just one, which might consititute 
the majority of them), you can "Merge with squashing" by clicking a 
checkbox: 
https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html. 
The UI will let you edit the commit message for the squashed commit 
before it is merged.

That would probably require using the Web UI; a hypothetical Emacs-based 
client might also support that later, IDK.

The alternative option is always there: when you don't want to squash 
all commits together (say, the branch is long and big), you can, of 
course, fetch it, check it out locally, rebase (fixing all commit 
messages while doing that) and push. And close the MR manually (I think 
automatic detection will break in the presence of rebasing).

>> And yes, GitLab adds the reference to the issue, which commit or PR resolves this issue.
> 
> What if the issue is not yet resolved, like when we commit a change
> that fixes only part of the issue, or is only tangentially related to
> it?  We cannot yet close the issue, but a reference to it should be in
> the commit log.

An issue reference doesn't have to close it. #123 is a reference. "Fixes 
#123" is an auto-closing reference. Some details here: 
https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html

To sum up, we can create references to issues in commits (which the 
GitLab UI recognizes as references), *and* we can make commits close 
issues. In the latter case the issue notes will reference the commit 
that closed it automatically.

>> About adding the copyright/paperworks, there isn’t a default setting, but you can have a bot to do that. I’ve never used one myself, so I’m not sure, but I’ve seen lots of projects that use bots to get paperwork, etc...
> 
> How can a bot do that, when a commit log message is immutable once the
> commit is pushed?

Is a commit message related to copyright/paperworks?

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, acm@muc.de,
>  toon@iotcl.com, agrambot@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 11 May 2019 16:13:09 +0300
> 
> >> About adding the copyright/paperworks, there isn’t a default setting, but you can have a bot to do that. I’ve never used one myself, so I’m not sure, but I’ve seen lots of projects that use bots to get paperwork, etc...
> > 
> > How can a bot do that, when a commit log message is immutable once the
> > commit is pushed?
> 
> Is a commit message related to copyright/paperworks?

It mentions when the commit didn't need (and didn't have) an
assignment, yes.  How else can we track such contributions?

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 11.05.2019 16:49, Eli Zaretskii wrote:
> It mentions when the commit didn't need (and didn't have) an
> assignment, yes.

Then, to answer your question, the bot can check that either the author 
either has copyright assignment, or the authored commits contain the "no 
assignment needed" line.

Also counting lines in the latter case is possible too, but I'd rather a 
human makes that judgment.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: pcr910303@icloud.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  acm@muc.de, toon@iotcl.com, agrambot@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 11 May 2019 16:57:29 +0300
> 
> On 11.05.2019 16:49, Eli Zaretskii wrote:
> > It mentions when the commit didn't need (and didn't have) an
> > assignment, yes.
> 
> Then, to answer your question, the bot can check that either the author 
> either has copyright assignment, or the authored commits contain the "no 
> assignment needed" line.

At what point in time will the bot check that?

> Also counting lines in the latter case is possible too, but I'd rather a 
> human makes that judgment.

Right, because the decision is not a mechanical one.

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: 조성빈 <pcr910303@icloud.com>
>> Date: Sat, 11 May 2019 16:38:30 +0900
>> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>>  acm@muc.de, toon@iotcl.com, agrambot@gmail.com
>> 
>> If you’re saying commit messages, you can view them and ask the contributors
>> to fix the messages, rebase the commits, and force-push them. You can merge
>> them afterwards.
>
> Asking the contributors to fix the log messages works only up to some
> not very far limit.  Quite frequently, IME, the 2nd, the 3rd, and
> sometimes the 4th attempt are still not what I'd like to see, whether
> due to misunderstanding or something else.  At which point I usually
> give up and fix the rest myself, so as not to discourage the
> contributor the next time he/she wants to contribute.
>
> Force-push is normally not an option, as our repository disallows
> that, to avoid someone's mistake corrupting the repository or losing
> data.
>
> So there should be an easy way of accepting a PR/MR where I can
> augment the log message in the process.  Because once the commit is
> pushed, whatever deficiencies there were in the log message are carved
> in stone forever.

I'm not sure if GitLab has added this feature yet, but GitHub pull
request submissions include a checkbox (default on) to allow the
project's maintainers to edit the pull request.  This means they are
allowed to push (forcefully or otherwise) changes to the submitter's
non-master branch before merging the pull request.

I don't find this a particularly "nice" way to work by default (so I'm
not advocating it), but I thought I'd mention it for completeness.

Thanks,

-- 
Basil

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: 조성빈 <pcr910303@icloud.com>
>> Date: Sat, 11 May 2019 12:47:27 +0900
>> Cc: Alex Gramiak <agrambot@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>>  emacs-devel@gnu.org, toon@iotcl.com, monnier@iro.umontreal.ca,
>>  dgutov@yandex.ru
>> 
>> So the outsider can ‘fork’ the repo, to make an exact clone of it,
>> push his/her changes(commits) to GitLab, and make a merge
>> request. The pull/merge request is a request the core contributor to
>> ‘pull’ the changes of the forked repo and ‘merge’ it just as if the
>> forked repo is just another branch.  This can be done by just
>> clicking a button to merge(in the web UI).
>
> Does "clicking a button" take care of various minor details I
> frequently need to do when applying patches from random contributors,
> such as fixing the log messages (or providing them in the first
> place), adding a reference to the bug/issue, adding the
> Copyright-paperwork-exempt tag, etc.?

No, but as I mentioned in my other message, you needn't use the button,
and can cause merge requests to be closed by pushing the relevant
changes to the target branch; GitLab then knows that the merge request
was merged.

I think the way it knows this is by checking that the commits comprising
the merge request are contained in the target branch.  This means that
any edits made to the commits outside of the merge request may confuse
GitLab, as the commit hashes will have changed (as Dmitry mentions
elsewhere).

In this case I think you need to either close the merge request manually
by clicking a button, or include an automatically stripped "quick
action" command such as "/close" in a comment to the merge request, or
make sure one of the merge request's commits include a similar command
such as "closes #123".

>> When the core contributor decides that the PR is done and merges it to the main repo, GitLab automatically
>> closes the issue. (If the PR was found to be an incomplete solution, the issue can be re-opened.)
>
> We currently have the opposite situation: pushing a fix doesn't
> automatically close the issue.  Both are bad as defaults, because IME
> what needs to be done is split roughly 50%.  So a much better UI would
> be to force the user to check a box when "clicking the merge button".

Given my description above, I think (in the case of GitLab) this would
be similar to the current requirement of including the bug number in log
messages, though its purpose would also be administrative, not just for
posterity.

Thanks,

-- 
Basil

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

조성빈 <pcr910303@icloud.com> writes:

> 2019. 5. 11. 오전 11:12, Alan Mackenzie <acm@muc.de> 작성:
>
>> I don't know what "pull/merge request" means.  Does it mean a request by
>> an outsider for a core contributor to perform a "git pull" operation
>> from the outsider's computer, the outsider having opened up his machine
>> to public access to allow this?
>
> An outsider that is not a core contributor cannot make a new branch
> (as he/she doesn’t have enough authorization).  So the outsider can
> ‘fork’ the repo, to make an exact clone of it, push his/her
> changes(commits) to GitLab, and make a merge request. The pull/merge
> request is a request the core contributor to ‘pull’ the changes of the
> forked repo and ‘merge’ it just as if the forked repo is just another
> branch.  This can be done by just clicking a button to merge(in the
> web UI).  Merging is also available in the command line; see
> https://gist.github.com/adam-p/15413fabef6cffecd897 ; but I’ve never
> seen anyone merging PRs like that in real life.

FWIW, I *never* use the GitLab/GitHub UI to either (a) edit files, (b)
create commits, or (c) merge merge/pull requests.

Editing files and commit messages in the browser is not only an inferior
experience to doing so in any decent text editor, but is also fraught
with potential issues like accidentally including undesirable
whitespace, omitting a trailing newline, etc.

Merging things with the click of a button means you don't know what's
actually happening, and I always want to control this process to the
greatest extent practical.  Luckily, Git makes this very easy - in my
personal workflow it's as simple as 'git merge --edit --no-ff'
(the --edit allows me to reference the merge request number in the merge
commit message).  Using a Git front-end such as Magit makes this even
easier.  When I then push the changes upstream, GitLab is smart enough
to know that the merge request has been merged and automatically closes
it.

-- 
Basil

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Alex.
>
> On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> > My point was that an absolute majority of Emacs issues don't have a
>> > patch attached.  They describe a problem, and most of the reports
>> > don't even include a detailed analysis of the problem and its root
>> > cause.  A large part of discussing an issue is devoted to
>> > understanding the issue and then finding its cause.  Patches appear
>> > only after all that.
>
>> > So we must have a good support for a workflow that doesn't include any
>> > pull/merge request at its beginning, maybe even never.
>
> I don't know what "pull/merge request" means.  Does it mean a request by
> an outsider for a core contributor to perform a "git pull" operation
> from the outsider's computer, the outsider having opened up his machine
> to public access to allow this?

A {pull,merge} request is a diff of two Git branches for which the issue
tracker cum Git forge (GitLab) creates a dedicated ticket with which
ensuing discussion and other metadata is associated.  In simplistic
terms, it's like an interactive set of patches.

The two branches in question are: (1) the branch containing the
submitter's proposed changes, and (2) the upstream branch these changes
are intended to be merged into.

The two branches can live either in the same repository, or in separate
"forks" (copies) of the same repository.  The former case means that the
submitter already has push access to the centralised upstream
repository.  The latter case is more common for first-time and
infrequent contributors who do not have push access, and thus have no
option but to create their merge requests (patch sets) against their
personal fork/copy/checkout of the upstream repository.

>> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
>> beginning, the topic is submitted as an "Issue" and given a unique issue
>> number. However, patches aren't submitted to the issue: rather, a new
>> PR/MR is created, given a unique MR number, and is linked with the
>> relevant issue(s).
>
> Yuck!  I recently worked with a proprietory system where each bug had
> several different numbers, an  issue number, an analysis number, a patch
> number, and so on.  It caused extra effort to keep track of bugs, and
> was generally horrible.

Each bug report ("issue") has only a single number.  Similarly each
merge request has only a single number.  Merge requests are often
submitted to address an existing issue, in which case the relevant Git
commit messages and/or merge request description canonically contain a
textual reference to this issue.  But it is up to the submitter and/or
reviewers to ensure such a reference is mentioned somewhere; the UI does
not force it upon anyone.

>> When the PR/MR is merged, any linked issues are closed.
>
> You needn't have used the passive voice, there.  What does your sentence
> mean?  That when a user merges a PR/MR, gitlab automatically closes the
> issue (whether it's finished, or not)?  Or that a user can close an
> issue only after somebody has first merged at least one PR/MR?  Or
> something else?
>
> What is the point of issues and PR/MRs having distinct identifiers, if
> they are so tightly coupled with eachother?

They are not that tightly coupled to each other.  Issues and merge
requests can be opened and closed independently of one another and in
any order, and each issue needn't be associated with a merge request,
and vice versa.  Even if they are associated, this association is mostly
implicit in the text of the discussion, not something imposed by GitLab.

As mentioned elsewhere in this thread, however, GitLab can automatically
take certain known actions based on specially crafted command phrases
included as part of commit messages or discussion comments, for
convenience.  For example, if a merge request contains a commit which
includes the phrase "Fixes #123", then merging the merge request
(i.e. merging its constituent commits into the upstream branch) causes
GitLab to automatically close bug number 123.  Similarly including an
automatically stripped command such as "/close" in a comment causes its
issue or merge request to be closed.

>> This means that the discussion gets separated into two parts: the
>> discussion about the issue/problem (kept in the "Issues" category), and
>> the discussion about the patch/solution (kept in the "Merge Requests"
>> category).
>
> This sounds like a Bad Thing to me.  It sounds rather like a workflow
> being imposed which imagines that first the bug gets "resolved"
> (whatever that means) in discussion, and only then does work start on a
> separate "merge request".  The above mentioned proprietory system was
> like this.  It didn't lend itself to a natural and efficient way of
> working.

The workflow is mostly up to the maintainers to design.  Issues and
merge requests are independent entities - one mustn't come before the
other.  The only difference is that issues are discussion-only (though
code snippets and diffs can of course be included as part of a comment,
and can even be prettified with syntax highlighting in the web UI),
whereas merge-requests additionally contain a realtime comparison of the
current state of two Git branches, and allow interactive commenting on
specific lines of the diff.  How issues and merge requests are used,
linked, labelled, etc. is up to the maintainers.

Thanks,

-- 
Basil

Re: [RFE] Migration to gitlab

[Alan Mackenzie]

Hello, Basil.

On Sat, May 11, 2019 at 20:22:56 +0100, Basil L. Contovounesios wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
> >> Eli Zaretskii <eliz@gnu.org> writes:

> >> > My point was that an absolute majority of Emacs issues don't have a
> >> > patch attached.  They describe a problem, and most of the reports
> >> > don't even include a detailed analysis of the problem and its root
> >> > cause.  A large part of discussing an issue is devoted to
> >> > understanding the issue and then finding its cause.  Patches appear
> >> > only after all that.

> >> > So we must have a good support for a workflow that doesn't include any
> >> > pull/merge request at its beginning, maybe even never.

> > I don't know what "pull/merge request" means.  Does it mean a request by
> > an outsider for a core contributor to perform a "git pull" operation
> > from the outsider's computer, the outsider having opened up his machine
> > to public access to allow this?

> A {pull,merge} request is a diff of two Git branches for which the issue
> tracker cum Git forge (GitLab) creates a dedicated ticket with which
> ensuing discussion and other metadata is associated.  In simplistic
> terms, it's like an interactive set of patches.

Is somebody requesting something?  OK, clearly that is the case in a
merge request, but it's less clear for a "pull request".

Is there also some name/process whereby somebody can submit a patch for
discussion, without the expectation it will be merged into master?  Kind
of "I think this patch might be a good idea because ...., what do you
say?"?

> The two branches in question are: (1) the branch containing the
> submitter's proposed changes, and (2) the upstream branch these changes
> are intended to be merged into.

> The two branches can live either in the same repository, or in separate
> "forks" (copies) of the same repository.  The former case means that the
> submitter already has push access to the centralised upstream
> repository.  The latter case is more common for first-time and
> infrequent contributors who do not have push access, and thus have no
> option but to create their merge requests (patch sets) against their
> personal fork/copy/checkout of the upstream repository.

Is the proposal here to allow an unauthenticated user to create forks on
the main server?  This feels like a bad idea: how's moderation to be
done?

> >> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
> >> beginning, the topic is submitted as an "Issue" and given a unique issue
> >> number. However, patches aren't submitted to the issue: rather, a new
> >> PR/MR is created, given a unique MR number, and is linked with the
> >> relevant issue(s).

> > Yuck!  I recently worked with a proprietory system where each bug had
> > several different numbers, an  issue number, an analysis number, a patch
> > number, and so on.  It caused extra effort to keep track of bugs, and
> > was generally horrible.

> Each bug report ("issue") has only a single number.  Similarly each
> merge request has only a single number.

So, each "issue" has its own number, and the numbers of each merge
request associated with it.  It seems to me that sometimes one number
will get used, sometimes another.  (As happened in the aforementioned
proprietory system.)

> Merge requests are often submitted to address an existing issue, in
> which case the relevant Git commit messages and/or merge request
> description canonically contain a textual reference to this issue.  But
> it is up to the submitter and/or reviewers to ensure such a reference
> is mentioned somewhere; the UI does not force it upon anyone.

> >> When the PR/MR is merged, any linked issues are closed.

> > You needn't have used the passive voice, there.  What does your sentence
> > mean?  That when a user merges a PR/MR, gitlab automatically closes the
> > issue (whether it's finished, or not)?  Or that a user can close an
> > issue only after somebody has first merged at least one PR/MR?  Or
> > something else?

> > What is the point of issues and PR/MRs having distinct identifiers, if
> > they are so tightly coupled with eachother?

> They are not that tightly coupled to each other.  Issues and merge
> requests can be opened and closed independently of one another and in
> any order, and each issue needn't be associated with a merge request,
> and vice versa.  Even if they are associated, this association is mostly
> implicit in the text of the discussion, not something imposed by GitLab.

I think the normal practice on Emacs, apart from for simple bugs, is for
somebody who isn't the author of the patch to close the bug, or at least
to confirm that it's fixed.

> As mentioned elsewhere in this thread, however, GitLab can automatically
> take certain known actions based on specially crafted command phrases
> included as part of commit messages or discussion comments, for
> convenience.  For example, if a merge request contains a commit which
> includes the phrase "Fixes #123", then merging the merge request
> (i.e. merging its constituent commits into the upstream branch) causes
> GitLab to automatically close bug number 123.  Similarly including an
> automatically stripped command such as "/close" in a comment causes its
> issue or merge request to be closed.

This doesn't sound like a good idea to me at the moment.  If I write
"Fixes bug #123" into a commit message, that usually expresses an
intention rather than a conclusion.  Surely closing bugs shouldn't happen
automatically, possibly by accident.

> >> This means that the discussion gets separated into two parts: the
> >> discussion about the issue/problem (kept in the "Issues" category), and
> >> the discussion about the patch/solution (kept in the "Merge Requests"
> >> category).

> > This sounds like a Bad Thing to me.  It sounds rather like a workflow
> > being imposed which imagines that first the bug gets "resolved"
> > (whatever that means) in discussion, and only then does work start on a
> > separate "merge request".  The above mentioned proprietory system was
> > like this.  It didn't lend itself to a natural and efficient way of
> > working.

> The workflow is mostly up to the maintainers to design.  Issues and
> merge requests are independent entities - one mustn't come before the
> other.  The only difference is that issues are discussion-only (though
> code snippets and diffs can of course be included as part of a comment,
> and can even be prettified with syntax highlighting in the web UI),
> whereas merge-requests additionally contain a realtime comparison of the
> current state of two Git branches, and allow interactive commenting on
> specific lines of the diff.  How issues and merge requests are used,
> linked, labelled, etc. is up to the maintainers.

OK.

> Thanks,

Thanks for the reply!

> -- 
> Basil

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Alan Mackenzie <acm@muc.de> writes:

> On Sat, May 11, 2019 at 20:22:56 +0100, Basil L. Contovounesios wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>
>> >> > My point was that an absolute majority of Emacs issues don't have a
>> >> > patch attached.  They describe a problem, and most of the reports
>> >> > don't even include a detailed analysis of the problem and its root
>> >> > cause.  A large part of discussing an issue is devoted to
>> >> > understanding the issue and then finding its cause.  Patches appear
>> >> > only after all that.
>
>> >> > So we must have a good support for a workflow that doesn't include any
>> >> > pull/merge request at its beginning, maybe even never.
>
>> > I don't know what "pull/merge request" means.  Does it mean a request by
>> > an outsider for a core contributor to perform a "git pull" operation
>> > from the outsider's computer, the outsider having opened up his machine
>> > to public access to allow this?
>
>> A {pull,merge} request is a diff of two Git branches for which the issue
>> tracker cum Git forge (GitLab) creates a dedicated ticket with which
>> ensuing discussion and other metadata is associated.  In simplistic
>> terms, it's like an interactive set of patches.
>
> Is somebody requesting something?  OK, clearly that is the case in a
> merge request, but it's less clear for a "pull request".

AFAIK, pull requests and merge requests are the same thing - the former
term is used by GitHub, and the latter by GitLab (there could be some
subtle difference, but IME they're effectively the same).

> Is there also some name/process whereby somebody can submit a patch for
> discussion, without the expectation it will be merged into master?  Kind
> of "I think this patch might be a good idea because ...., what do you
> say?"?

GitHub pull requests can be marked as "drafts" on creation (this is a
relatively new feature), but I'm not sure if GitLab supports this yet.
Either way, this is not an essential feature - there are other ways to
convey the intention, e.g. by using a particular label or by using one's
words.  I've often seen people prepend their merge request titles with
"[WIP]", for example.  It's up to the maintainers and submitters to
determine what kind of convention they want to follow, given GitLab's
features.

>> The two branches in question are: (1) the branch containing the
>> submitter's proposed changes, and (2) the upstream branch these changes
>> are intended to be merged into.
>
>> The two branches can live either in the same repository, or in separate
>> "forks" (copies) of the same repository.  The former case means that the
>> submitter already has push access to the centralised upstream
>> repository.  The latter case is more common for first-time and
>> infrequent contributors who do not have push access, and thus have no
>> option but to create their merge requests (patch sets) against their
>> personal fork/copy/checkout of the upstream repository.
>
> Is the proposal here to allow an unauthenticated user to create forks on
> the main server?  This feels like a bad idea: how's moderation to be
> done?

I can imagine an arrangement not too dissimilar to Savannah: each
submitter will first have to create an account on the GitLab instance.
I'm not sure who will be administering this instance in practice,
though, or how.

One alternative would be cross-GitLab-instance merge requests, but a
quick online search suggests this is not yet implemented:

https://gitlab.com/gitlab-org/gitlab-ce/issues/1919
https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
https://gitlab.com/gitlab-org/gitlab-ce/issues/47191

>> >> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
>> >> beginning, the topic is submitted as an "Issue" and given a unique issue
>> >> number. However, patches aren't submitted to the issue: rather, a new
>> >> PR/MR is created, given a unique MR number, and is linked with the
>> >> relevant issue(s).
>
>> > Yuck!  I recently worked with a proprietory system where each bug had
>> > several different numbers, an  issue number, an analysis number, a patch
>> > number, and so on.  It caused extra effort to keep track of bugs, and
>> > was generally horrible.
>
>> Each bug report ("issue") has only a single number.  Similarly each
>> merge request has only a single number.
>
> So, each "issue" has its own number, and the numbers of each merge
> request associated with it.  It seems to me that sometimes one number
> will get used, sometimes another.  (As happened in the aforementioned
> proprietory system.)

I'm not sure what makes you think that.  Each number uniquely identifies
a completely independent entity.  If you want to refer to a particular
issue, you use that issue's ID.  If you want to refer to a particular
merge request, you use that merge request's ID.  You cannot refer to an
issue by the ID of any associated merge requests, and vice versa.

>> Merge requests are often submitted to address an existing issue, in
>> which case the relevant Git commit messages and/or merge request
>> description canonically contain a textual reference to this issue.  But
>> it is up to the submitter and/or reviewers to ensure such a reference
>> is mentioned somewhere; the UI does not force it upon anyone.
>
>> >> When the PR/MR is merged, any linked issues are closed.
>
>> > You needn't have used the passive voice, there.  What does your sentence
>> > mean?  That when a user merges a PR/MR, gitlab automatically closes the
>> > issue (whether it's finished, or not)?  Or that a user can close an
>> > issue only after somebody has first merged at least one PR/MR?  Or
>> > something else?
>
>> > What is the point of issues and PR/MRs having distinct identifiers, if
>> > they are so tightly coupled with eachother?
>
>> They are not that tightly coupled to each other.  Issues and merge
>> requests can be opened and closed independently of one another and in
>> any order, and each issue needn't be associated with a merge request,
>> and vice versa.  Even if they are associated, this association is mostly
>> implicit in the text of the discussion, not something imposed by GitLab.
>
> I think the normal practice on Emacs, apart from for simple bugs, is for
> somebody who isn't the author of the patch to close the bug, or at least
> to confirm that it's fixed.

The same practice can be followed using GitLab.

>> As mentioned elsewhere in this thread, however, GitLab can automatically
>> take certain known actions based on specially crafted command phrases
>> included as part of commit messages or discussion comments, for
>> convenience.  For example, if a merge request contains a commit which
>> includes the phrase "Fixes #123", then merging the merge request
>> (i.e. merging its constituent commits into the upstream branch) causes
>> GitLab to automatically close bug number 123.  Similarly including an
>> automatically stripped command such as "/close" in a comment causes its
>> issue or merge request to be closed.
>
> This doesn't sound like a good idea to me at the moment.  If I write
> "Fixes bug #123" into a commit message, that usually expresses an
> intention rather than a conclusion.  Surely closing bugs shouldn't happen
> automatically, possibly by accident.

IME it rarely happens by accident, and can be reversed when it does.
GitLab can probably be configured to disable these features (in the
future if not already).  They are provided for convenience, so if they
fail to be that can simply not be used.

>> >> This means that the discussion gets separated into two parts: the
>> >> discussion about the issue/problem (kept in the "Issues" category), and
>> >> the discussion about the patch/solution (kept in the "Merge Requests"
>> >> category).
>
>> > This sounds like a Bad Thing to me.  It sounds rather like a workflow
>> > being imposed which imagines that first the bug gets "resolved"
>> > (whatever that means) in discussion, and only then does work start on a
>> > separate "merge request".  The above mentioned proprietory system was
>> > like this.  It didn't lend itself to a natural and efficient way of
>> > working.
>
>> The workflow is mostly up to the maintainers to design.  Issues and
>> merge requests are independent entities - one mustn't come before the
>> other.  The only difference is that issues are discussion-only (though
>> code snippets and diffs can of course be included as part of a comment,
>> and can even be prettified with syntax highlighting in the web UI),
>> whereas merge-requests additionally contain a realtime comparison of the
>> current state of two Git branches, and allow interactive commenting on
>> specific lines of the diff.  How issues and merge requests are used,
>> linked, labelled, etc. is up to the maintainers.
>
> OK.
>
>> Thanks,
>
> Thanks for the reply!

Ditto. :)

-- 
Basil

Re: [RFE] Migration to gitlab

[Simon Leinen]

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

On Sun, May 12, 2019 at 11:09 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:

> Alan Mackenzie <acm@muc.de> writes:
>
> > Is there also some name/process whereby somebody can submit a patch for
> > discussion, without the expectation it will be merged into master?  Kind
> > of "I think this patch might be a good idea because ...., what do you
> > say?"?
>
> GitHub pull requests can be marked as "drafts" on creation (this is a
> relatively new feature), but I'm not sure if GitLab supports this yet.
>

GitLab has (and has had for quite some time) the convention of using "WIP:
..." in the title of the MR (Merge Request).
-- 
Simon.

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

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Simon Leinen <simon.leinen@gmail.com> writes:

> On Sun, May 12, 2019 at 11:09 PM Basil L. Contovounesios <contovob@tcd.ie> wrote:
>
>  Alan Mackenzie <acm@muc.de> writes:
>
>  > Is there also some name/process whereby somebody can submit a patch for
>  > discussion, without the expectation it will be merged into master?  Kind
>  > of "I think this patch might be a good idea because ...., what do you
>  > say?"?
>
>  GitHub pull requests can be marked as "drafts" on creation (this is a
>  relatively new feature), but I'm not sure if GitLab supports this yet.
>
> GitLab has (and has had for quite some time) the convention of using
> "WIP: ..." in the title of the MR (Merge Request).

Does GitLab handle such titles specially?  Because if not, then they're
no different to doing the same in GitHub or email.

-- 
Basil

Re: [RFE] Migration to gitlab

[Simon Leinen]

[-- Attachment #1.1: Type: text/plain, Size: 645 bytes --]

On Wed, Jun 26, 2019 at 12:38 AM Basil L. Contovounesios <contovob@tcd.ie>
wrote:

> Simon Leinen <simon.leinen@gmail.com> writes:
>
> > GitLab has (and has had for quite some time) the convention of using
> > "WIP: ..." in the title of the MR (Merge Request).
>
> Does GitLab handle such titles specially?  Because if not, then they're
> no different to doing the same in GitHub or email.
>

Yes, it does.  When the "WIP:" is present, GitLab's Web UI will not offer
(reviewers) the option to merge the change.  Instead, it will notify that
the change is Work In Progress, and offer a button that removes
("resolves") the WIP status.
-- 
Simon.

[-- Attachment #1.2: Type: text/html, Size: 1089 bytes --]

[-- Attachment #2: Screenshot 2019-06-26 at 19.58.54 .png --]
[-- Type: image/png, Size: 15282 bytes --]

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Simon Leinen <simon.leinen@gmail.com> writes:

> On Wed, Jun 26, 2019 at 12:38 AM Basil L. Contovounesios <contovob@tcd.ie> wrote:
>
>  Simon Leinen <simon.leinen@gmail.com> writes:
>
>  > GitLab has (and has had for quite some time) the convention of using
>  > "WIP: ..." in the title of the MR (Merge Request).
>
>  Does GitLab handle such titles specially?  Because if not, then they're
>  no different to doing the same in GitHub or email.
>
> Yes, it does.  When the "WIP:" is present, GitLab's Web UI will not
> offer (reviewers) the option to merge the change.  Instead, it will
> notify that the change is Work In Progress, and offer a button that
> removes ("resolves") the WIP status.

Thank you for explaining, that's good to know.

-- 
Basil

Re: [RFE] Migration to gitlab

[Alex Gramiak]

Hi, Alan.

Alan Mackenzie <acm@muc.de> writes:

> I don't know what "pull/merge request" means.  Does it mean a request by
> an outsider for a core contributor to perform a "git pull" operation
> from the outsider's computer, the outsider having opened up his machine
> to public access to allow this?

Typically a local copy of the repository is uploaded somewhere else so
that the server can access the branch. Outsiders should be able to make
an account on a hypothetical GNU Gitlab instance, push their repository
to their account, and then have the MR be between that repository and
the upstream in the GNU Gitlab instance. For example, [1] (under Using a
fork - Non GNOME developer) describes how this process works for
outsiders for the GNOME project.

Basil gave a good description of pull/merge requests, but here[2] is an
example picture of a merge request in the Gitlab web UI.

The main body consists of a topic and MR comment, which includes several
sections in Markdown and a special phrase "Closes #46869" that will
automatically close issue #46869 when the MR is accepted. The phrase can
also occur in a commit message instead of the MR message.

The right sidebar includes some metadata like the assignee, milestone,
labels, and participant list.

Below the comment is the status of the MR. Below that is the discussion,
list of commits, the pipelines[3], and the diff of the MR.

>> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
>> beginning, the topic is submitted as an "Issue" and given a unique issue
>> number. However, patches aren't submitted to the issue: rather, a new
>> PR/MR is created, given a unique MR number, and is linked with the
>> relevant issue(s).
>
> Yuck!  I recently worked with a proprietory system where each bug had
> several different numbers, an  issue number, an analysis number, a patch
> number, and so on.  It caused extra effort to keep track of bugs, and
> was generally horrible.

That indeed sounds awful, but IMO the Gitlab style is different as there
are only two categories, with the bug (an issue) having a single ID, and
a set of MRs containing separate IDs. Keeping track of bugs would
usually just involve using the issue number, not the MR number.

>> When the PR/MR is merged, any linked issues are closed.
>
> You needn't have used the passive voice, there.  What does your sentence
> mean?  That when a user merges a PR/MR, gitlab automatically closes the
> issue (whether it's finished, or not)?

Only if the submitter (or merger if the server allows) specifies that
the MR closes the issue. See [4] for how Gitlab handles this.

>> This means that the discussion gets separated into two parts: the
>> discussion about the issue/problem (kept in the "Issues" category), and
>> the discussion about the patch/solution (kept in the "Merge Requests"
>> category).
>
> This sounds like a Bad Thing to me.  It sounds rather like a workflow
> being imposed which imagines that first the bug gets "resolved"
> (whatever that means) in discussion, and only then does work start on a
> separate "merge request".  The above mentioned proprietory system was
> like this.  It didn't lend itself to a natural and efficient way of
> working.

To reiterate what Basil said, it's up to the maintainers in how MRs
would be used (though too significant of a departure from the standard
would detract from the newcomer-friendly aspect of this move). All
discussion could be in the issue with no comments in the MR outside of
comments specifically about the implementation of the MR.

I can see how the workflow could include some aspects that might be
somewhat unnatural/inefficient (such as a discussion about the bug in
the MR that has to be summarized/duplicated/linked in the issue), but I
don't think that it's much of a deal in this type of system. As with any
system, a certain class of workflows is imposed, but this system, while
encouraging a thorough discussion on the issue side first, can still
have MR(s) being worked on while the discussion in the issue is ongoing.
It's just that the discussion for the MR is separated from the issue at
large. One can think of the MR discussion as a separate email subthread
for the main/issue thread.

[1] https://wiki.gnome.org/GitLab

[2]
https://docs.gitlab.com/ee/user/project/merge_requests/img/merge_request.png

[3] https://docs.gitlab.com/ee/ci/pipelines.html


[4] https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: toon@iotcl.com,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
> Date: Fri, 10 May 2019 16:23:03 -0600
> 
> > So we must have a good support for a workflow that doesn't include any
> > pull/merge request at its beginning, maybe even never.
> 
> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
> beginning, the topic is submitted as an "Issue" and given a unique issue
> number.

What interests me is which features make discussing an issue easier
than with debbugs.  What you describe above is in general identical to
how we do that on debbugs (except that there's no Web UI).

> However, patches aren't submitted to the issue: rather, a new
> PR/MR is created, given a unique MR number, and is linked with the
> relevant issue(s). When the PR/MR is merged, any linked issues are
> closed.
> 
> This means that the discussion gets separated into two parts: the
> discussion about the issue/problem (kept in the "Issues" category), and
> the discussion about the patch/solution (kept in the "Merge Requests"
> category).

This separation is IME not a good thing.  Integrated issue trackers
should have them both together.  I should be able to create a PR/MR
directly from the issue, or vice versa, instead of creating a new
object and then linking it to an old one.  But maybe in practice this
separation is not important enough to care about.

Re: [RFE] Migration to gitlab

[Alex Gramiak]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex Gramiak <agrambot@gmail.com>
>> Cc: toon@iotcl.com,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
>> Date: Fri, 10 May 2019 16:23:03 -0600
>> 
>> > So we must have a good support for a workflow that doesn't include any
>> > pull/merge request at its beginning, maybe even never.
>> 
>> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
>> beginning, the topic is submitted as an "Issue" and given a unique issue
>> number.
>
> What interests me is which features make discussing an issue easier
> than with debbugs.  What you describe above is in general identical to
> how we do that on debbugs (except that there's no Web UI).

I'm not sure about features regarding the discussion itself (though
resolvable discussions[0] might be useful), but the administrative
aspect is (mostly*) more detailed and accessible than debbugs'. [1] is
an overview of issues, [2] is an overview of issue boards, [3] includes
a labeled picture of a typical issue page, and [4] describes the
crosslinking between issues/MRs.

>> However, patches aren't submitted to the issue: rather, a new
>> PR/MR is created, given a unique MR number, and is linked with the
>> relevant issue(s). When the PR/MR is merged, any linked issues are
>> closed.
>> 
>> This means that the discussion gets separated into two parts: the
>> discussion about the issue/problem (kept in the "Issues" category), and
>> the discussion about the patch/solution (kept in the "Merge Requests"
>> category).
>
> This separation is IME not a good thing.  Integrated issue trackers
> should have them both together.  I should be able to create a PR/MR
> directly from the issue

This can be done (see number 18 in [3]).

> , or vice versa, instead of creating a new
> object and then linking it to an old one.

Typically one would create the issue first and make the MR later, and
FWIW Gitlab recommends[5] always doing that. Though if a stand-alone MR
turns out that it needs a more general discussion that warrants an
issue, then creating a new issue and linking the two is trivial and not
so different than creating a new thread in emacs-devel that references a
discussion on debbugs.

> But maybe in practice this separation is not important enough to care
> about.

I think that the separation works out in practice after getting used to
it, as long as there's not a plethora of separations like Alan
mentioned.


* Seems there's no "blocking issue" feature in Gitlab yet[6], but if the
  only use for this is release blocking, then using a milestone should be
  sufficient.

P.S. Another feature that would be nice is protected branches[7], which
I believe would allow for, e.g., release branches to be closed off for
commits (which was discussed recently), and for scratch branches to be
rebased (while disallowing rebasing for other branches).

[0]
https://docs.gitlab.com/ce/user/discussions/index.html#resolvable-comments-and-discussions

[1] https://docs.gitlab.com/ce/user/project/issues/

[2] https://docs.gitlab.com/ce/user/project/issue_board.html

[3]
https://docs.gitlab.com/ce/user/project/issues/issue_data_and_actions.html

[4]
https://docs.gitlab.com/ce/user/project/issues/crosslinking_issues.html

[5] https://about.gitlab.com/2016/03/03/start-with-an-issue/

[6] https://gitlab.com/gitlab-org/gitlab-ee/issues/2035

[7] https://docs.gitlab.com/ce/user/project/protected_branches.html

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: toon@iotcl.com,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
> Date: Sat, 11 May 2019 18:23:36 -0600
> 
> I'm not sure about features regarding the discussion itself (though
> resolvable discussions[0] might be useful), but the administrative
> aspect is (mostly*) more detailed and accessible than debbugs'. [1] is
> an overview of issues, [2] is an overview of issue boards, [3] includes
> a labeled picture of a typical issue page, and [4] describes the
> crosslinking between issues/MRs.

Thanks, that was useful reading.

> P.S. Another feature that would be nice is protected branches[7], which
> I believe would allow for, e.g., release branches to be closed off for
> commits (which was discussed recently), and for scratch branches to be
> rebased (while disallowing rebasing for other branches).

Does this protect only the GitLab's copy of the upstream repository,
or can we also protect branches on Savannah via this mechanism?

Re: [RFE] Migration to gitlab

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> P.S. Another feature that would be nice is protected branches[7],
>> which I believe would allow for, e.g., release branches to be closed
>> off for commits (which was discussed recently), and for scratch
>> branches to be rebased (while disallowing rebasing for other
>> branches).
>
> Does this protect only the GitLab's copy of the upstream repository,
> or can we also protect branches on Savannah via this mechanism?

I think protected branches is some administrative feature provided by
GitLab & GitHub and not git itself.

BTW, I'm a Magit user and recently started using Forge for creating
issues and PRs for some 3rd party emacs packages hosted on GitHub, and
its UI is really intuitive and emacsy.  I like it very much.

However, I'm not sure if it would scale for a large project like emacs.
At least the initial pull of issues and pull/merge requests may take
some time.  I've used it with the Magit GitHub repo which is very active
and has many issues/PRs, but those numbers are tiny in comparison to
what emacs would have when all debbugs issues would be GitLab issues.

Also, I'm not sure if it would work out UI-wise at the current point in
time.  AFAIK, Forge simply shows all open issues in a collapsable list,
and it's a different thing if your project has two dozens or several
thousands of open issues.  I'm not sure if you can do some kind of
filtering/searching/scoring right now (other than isearching, of
course).

Another aspect is that GitLab (and GitHub) use Markdown in comments and
discussions, so we'd need to adapt our formatting style, e.g., `symbol`
instead of `symbol', and

```elisp
(foo (bar 'baz))
```

for code blocks, and don't hard-wrap text at some column.  At least you
better do that if the stuff should look good also in the web interface.
(Forge also fontifies that nicely.)

So all in all, I think that GitLab is a good tool, and it's nicely
accessible from inside Emacs using Magit + Forge.  But as long as
there's no test emacs project inside some GitLab instance where all open
debbugs bugs have been converted to issues, every feasibility argument
is just a hypothetical one.

Bye,
Tassilo

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Alex Gramiak <agrambot@gmail.com>,  toon@iotcl.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 12 May 2019 09:04:22 +0200
> 
> Another aspect is that GitLab (and GitHub) use Markdown in comments and
> discussions, so we'd need to adapt our formatting style, e.g., `symbol`
> instead of `symbol', and
> 
> ```elisp
> (foo (bar 'baz))
> ```
> 
> for code blocks, and don't hard-wrap text at some column.  At least you
> better do that if the stuff should look good also in the web interface.
> (Forge also fontifies that nicely.)

Ugh, yet another style to learn and get used to!

Re: [RFE] Migration to gitlab

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> However, I'm not sure if it would scale for a large project like emacs.
> At least the initial pull of issues and pull/merge requests may take
> some time.

FWIW, GNOME migrated to GitLab, so their projects can be used for
testing at least the scalability to some extend.

Yesterday, after writing the above, I've checked out the gtk project and
enabled Magit/Forge on it.  The initial fetch of the topics (~1900
issues and ~800 merge requests) took about two hours, but contrary to
what has been reported in another message in this thread, it did not
crash and indicated its progess in the mode-line (something like pulling
1211/1871 Issues).

The UI also doesn't feel sluggish with that number of issues/merge
requests.  And AFAIK, Forge puts all issues and merge requests in a
SQLite database so you have them all locally and efficient querying
according to labels, assignees, severity, state or whatever attributes
an issue/MR has should be straight-forward to implement (if not yet
available).

Bye,
Tassilo

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Alex Gramiak <agrambot@gmail.com>,  toon@iotcl.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 13 May 2019 06:32:21 +0200
> 
> Yesterday, after writing the above, I've checked out the gtk project and
> enabled Magit/Forge on it.  The initial fetch of the topics (~1900
> issues and ~800 merge requests) took about two hours, but contrary to
> what has been reported in another message in this thread, it did not
> crash and indicated its progess in the mode-line (something like pulling
> 1211/1871 Issues).

1900 issues is about an order of magnitude less than what we have,
AFAIU, so 2 hours is quite a lot.  Also, I'm not sure Clément tried
this DB, perhaps he tried a larger one.

Why does Forge insist downloading the entire DB to the local machine?
That sounds like something that wouldn't scale well.

Re: [RFE] Migration to gitlab

[Clément Pit-Claudel]

On 2019-05-13 10:51, Eli Zaretskii wrote:
>> From: Tassilo Horn <tsdh@gnu.org> Cc: Alex Gramiak
>> <agrambot@gmail.com>,  toon@iotcl.com,  dgutov@yandex.ru,
>> monnier@iro.umontreal.ca,  emacs-devel@gnu.org Date: Mon, 13 May
>> 2019 06:32:21 +0200
>> 
>> Yesterday, after writing the above, I've checked out the gtk
>> project and enabled Magit/Forge on it.  The initial fetch of the
>> topics (~1900 issues and ~800 merge requests) took about two hours,
>> but contrary to what has been reported in another message in this
>> thread, it did not crash and indicated its progess in the mode-line
>> (something like pulling 1211/1871 Issues).
> 
> 1900 issues is about an order of magnitude less than what we have, 
> AFAIU, so 2 hours is quite a lot.  Also, I'm not sure Clément tried 
> this DB, perhaps he tried a larger one.

Correct: I tried a larger one (77'000 `topics', i.e. 50 thousand issues and 27 thousand patch discussions).  

Jonas, the creator of forge, reports in the Github discussion (https://github.com/magit/ghub/issues/87) that fetching problems are usually due to intermittent connectivity issues, and that retrying sometimes fixes them.  Here is an extra bit of relevant information [this is in reply to Toon inquiring about GraphQL]:

> Fetching the needed data from Github using GraphQL [this is the
> protocol I mentionned earlier] is much faster than fetching it from
> Gitlab using REST. I don't remember exactly but I think that what
> would take ten minutes for Github would take hours for Gitlab. I
> would like Forge to be usable for projects like Emacs itself but it
> is still early days and a lot has to be done before that is really
> feasible. With GraphQL it would become possible at least, but the
> initial fetch might still take hours anyway. Regardless of what you
> do (and I would very much welcome GraphQL support) I think ghub/forge
> has to learn to do sparse clones, just like git did.

[OFFTOPIC] size of issue tracker (was: [RFE] Migration to gitlab)

[Stefan Monnier]

> Yesterday, after writing the above, I've checked out the gtk project and
> enabled Magit/Forge on it.  The initial fetch of the topics (~1900
> issues and ~800 merge requests) took about two hours, but contrary to
> what has been reported in another message in this thread, it did not

Not sure if this time is spent on turn-around time or actual transfer or
what, but FWIW, my proof-of-concept BuGit issue-tracking-system kept the
whole 20 thousand or so issues of debbugs.gnu.org in a Git repo that was
less than 10MB, IIRC, so cloning the whole thing takes much less than
2 hours, even on a slow connection.

One of the reasons why I really wish for a bug tracker that keeps the
issues in Git (and no, sadly, BuGit is not up-to-the-task, it's just
a 100KB proof-of-concept shell script).

> Why does Forge insist downloading the entire DB to the local machine?
> That sounds like something that wouldn't scale well.

I don't know why it does so, but it sounds like a good idea to me, so
you can later use them when you're offline.


        Stefan

Re: [OFFTOPIC] size of issue tracker (was: [RFE] Migration to gitlab)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Alex Gramiak <agrambot@gmail.com>,  toon@iotcl.com,  dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Mon, 13 May 2019 12:41:25 -0400
> 
> > Why does Forge insist downloading the entire DB to the local machine?
> > That sounds like something that wouldn't scale well.
> 
> I don't know why it does so, but it sounds like a good idea to me, so
> you can later use them when you're offline.

If the DB is small enough, sure.  It sounds like somehow it isn't the
case with Forge and GitLab.

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

> If the DB is small enough, sure.  It sounds like somehow it isn't the
> case with Forge and GitLab.

As my experiment with BuGit shows, even the 20 thousand issues that were
in debbugs.gnu.org at that time can be brought down to 10MB, which
is the equivalent of a small handful of adds on an average
webpage, I think.

And of course forge.el can store it locally in an efficient way (I
doubt the sqlite they use will be anywhere near that efficient, tho).
It seems that Gitlab doesn't offer an API that makes it possible
to download such large number of issues in an efficient way, or forge.el
doesn't know how to use it.


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Óscar Fuentes]

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

>> If the DB is small enough, sure.  It sounds like somehow it isn't the
>> case with Forge and GitLab.
>
> As my experiment with BuGit shows, even the 20 thousand issues that were
> in debbugs.gnu.org at that time can be brought down to 10MB,

That does not include file attachments, does it?

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

>>> If the DB is small enough, sure.  It sounds like somehow it isn't the
>>> case with Forge and GitLab.
>> As my experiment with BuGit shows, even the 20 thousand issues that were
>> in debbugs.gnu.org at that time can be brought down to 10MB,
> That does not include file attachments, does it?

I think it did.
But I must admit that I can't find my test repo, so I can't confirm.


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Why does Forge insist downloading the entire DB to the local
>> > machine?  That sounds like something that wouldn't scale well.
>> 
>> I don't know why it does so, but it sounds like a good idea to me, so
>> you can later use them when you're offline.
>
> If the DB is small enough, sure.  It sounds like somehow it isn't the
> case with Forge and GitLab.

My database (~/.emacs.d/forge-database.sqlite) is currently 38 MB, and
it contains the contents of 4 different projects from which gtk with its
1900 issues and 900 MRs is by far the largest one.  There's a repository
table from which you can join your way to the issues, merge/pull
requests, their comments, labels, and assignees.

That's the current schema if you are interested in details.

--8<---------------cut here---------------start------------->8---
sqlite> .schema
CREATE TABLE repository (class NOT NULL, id NOT NULL PRIMARY KEY, forge_id , forge , owner , name , apihost , githost , remote , sparse_p , created , updated , pushed , parent , description , homepage , default_branch , archived_p , fork_p , locked_p , mirror_p , private_p , issues_p , wiki_p , stars , watchers , assignees DEFAULT eieio_unbound, forks DEFAULT eieio_unbound, issues DEFAULT eieio_unbound, labels DEFAULT eieio_unbound, revnotes DEFAULT eieio_unbound, pullreqs DEFAULT eieio_unbound);
CREATE TABLE assignee (repository NOT NULL, id NOT NULL PRIMARY KEY, login , name , forge_id , FOREIGN KEY (repository) REFERENCES repository (id) ON DELETE CASCADE);
CREATE TABLE fork (parent NOT NULL, id NOT NULL PRIMARY KEY, owner , name , FOREIGN KEY (parent) REFERENCES repository (id) ON DELETE CASCADE);
CREATE TABLE issue (class NOT NULL, id NOT NULL PRIMARY KEY, repository , number , state , author , title , created , updated , closed , unread_p , locked_p , milestone , body , assignees DEFAULT eieio_unbound, cards DEFAULT eieio_unbound, edits DEFAULT eieio_unbound, labels DEFAULT eieio_unbound, participants DEFAULT eieio_unbound, posts DEFAULT eieio_unbound, reactions DEFAULT eieio_unbound, timeline DEFAULT eieio_unbound, FOREIGN KEY (repository) REFERENCES repository (id) ON DELETE CASCADE);
CREATE TABLE issue_assignee (issue NOT NULL, id NOT NULL, FOREIGN KEY (issue) REFERENCES issue (id) ON DELETE CASCADE);
CREATE TABLE issue_label (issue NOT NULL, id NOT NULL, FOREIGN KEY (issue) REFERENCES issue (id) ON DELETE CASCADE, FOREIGN KEY (id) REFERENCES label (id) ON DELETE CASCADE);
CREATE TABLE issue_post (class NOT NULL, id NOT NULL PRIMARY KEY, issue , number , author , created , updated , body , edits DEFAULT eieio_unbound, reactions DEFAULT eieio_unbound, FOREIGN KEY (issue) REFERENCES issue (id) ON DELETE CASCADE);
CREATE TABLE label (repository NOT NULL, id NOT NULL PRIMARY KEY, name , color , description , FOREIGN KEY (repository) REFERENCES repository (id) ON DELETE CASCADE);
CREATE TABLE notification (class NOT NULL, id NOT NULL PRIMARY KEY, repository , forge , reason , unread_p , last_read , updated , title , type , topic , url , FOREIGN KEY (repository) REFERENCES repository (id) ON DELETE CASCADE);
CREATE TABLE pullreq (class NOT NULL, id NOT NULL PRIMARY KEY, repository , number , state , author , title , created , updated , closed , merged , unread_p , locked_p , editable_p , cross_repo_p , base_ref , base_repo , head_ref , head_user , head_repo , milestone , body , assignees DEFAULT eieio_unbound, cards DEFAULT eieio_unbound, commits DEFAULT eieio_unbound, edits DEFAULT eieio_unbound, labels DEFAULT eieio_unbound, participants DEFAULT eieio_unbound, posts DEFAULT eieio_unbound, reactions DEFAULT eieio_unbound, review_requests DEFAULT eieio_unbound, reviews DEFAULT eieio_unbound, timeline DEFAULT eieio_unbound, FOREIGN KEY (repository) REFERENCES repository (id) ON DELETE CASCADE);
CREATE TABLE pullreq_assignee (pullreq NOT NULL, id NOT NULL, FOREIGN KEY (pullreq) REFERENCES pullreq (id) ON DELETE CASCADE);
CREATE TABLE pullreq_label (pullreq NOT NULL, id NOT NULL, FOREIGN KEY (pullreq) REFERENCES pullreq (id) ON DELETE CASCADE, FOREIGN KEY (id) REFERENCES label (id) ON DELETE CASCADE);
CREATE TABLE pullreq_post (class NOT NULL, id NOT NULL PRIMARY KEY, pullreq , number , author , created , updated , body , edits DEFAULT eieio_unbound, reactions DEFAULT eieio_unbound, FOREIGN KEY (pullreq) REFERENCES pullreq (id) ON DELETE CASCADE);
CREATE TABLE revnote (class NOT NULL, id NOT NULL PRIMARY KEY, repository , "commit" , file , line , author , body , FOREIGN KEY (repository) REFERENCES repository (id) ON DELETE CASCADE);
--8<---------------cut here---------------end--------------->8---

Fetching all new 19 issues & 10 MRs since my initial 2-hour fetch
yesterday took about 3 minutes.

I think the bottleneck here is the current GitLab API.  If I find some
time, I can re-run the procedure with an even bigger GitHub project.
I've read GitHub has a more efficient GraphQL API for this stuff, and
AFAIK, GitLab is or will implement something similar, so this slowness
might be resolved in the mid-term future.

If you have a preference for some project hosted on GitHub (e.g.,
because it has about the same numbers of issues as we have), drop me a
mail.

Bye,
Tassilo

Re: [OFFTOPIC] size of issue tracker

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> I think the bottleneck here is the current GitLab API.  If I find some
> time, I can re-run the procedure with an even bigger GitHub project.
> I've read GitHub has a more efficient GraphQL API for this stuff, and
> AFAIK, GitLab is or will implement something similar, so this slowness
> might be resolved in the mid-term future.
>
> If you have a preference for some project hosted on GitHub (e.g.,
> because it has about the same numbers of issues as we have), drop me a
> mail.

I was too curious to wait so I've tried the flutter project on GitHub
with its 20,000 issues and 12,000 pull requests.  That took about 45
minutes which is ok, I think.

Bye,
Tassilo

Re: [OFFTOPIC] size of issue tracker

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> I was too curious to wait so I've tried the flutter project on GitHub
> with its 20,000 issues and 12,000 pull requests.  That took about 45
> minutes which is ok, I think.

Ah, I forgot to mention that it increased the size of the sqlite
database by about 200 MB.  The flutter git repo itself has about the
same size after "git gc --aggressive" with its 14,000 commits.

Bye,
Tassilo

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

>> I was too curious to wait so I've tried the flutter project on GitHub
>> with its 20,000 issues and 12,000 pull requests.  That took about 45
>> minutes which is ok, I think.
> Ah, I forgot to mention that it increased the size of the sqlite
> database by about 200 MB.  The flutter git repo itself has about the

45 minutes for 200MB (i.e. 74KB/s) indicates either that you have a very
slow connection, or that a lot of time is spent waiting, or that the
protocol is sending a lot more data than needed (even my slow
connection can download almost 3GB of data during those 45 minutes).


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Toon Claes]

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

Tassilo Horn <tsdh@gnu.org> writes:

> I think the bottleneck here is the current GitLab API.  If I find some
> time, I can re-run the procedure with an even bigger GitHub project.
> I've read GitHub has a more efficient GraphQL API for this stuff, and
> AFAIK, GitLab is or will implement something similar, so this slowness
> might be resolved in the mid-term future.

Yeah, the GitLab API doesn't have a great reputation regarding
speed. Although you are probably testing on GitLab.com. That instance of
GitLab has a tremendious database of issues. If we would do similar
tests on EMBA, I hope we'd get better results. But we only know for sure
if we do a real test. I'll try to set up such test later this week.


-- 
Toon

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

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

> Not sure if this time is spent on turn-around time or actual transfer or
> what, but FWIW, my proof-of-concept BuGit issue-tracking-system kept the
> whole 20 thousand or so issues of debbugs.gnu.org in a Git repo that was
> less than 10MB, IIRC, so cloning the whole thing takes much less than
> 2 hours, even on a slow connection.

OK, I finally tracked down the disk where I kept this experiment.
And indeed, I see that the past looks always much better than it really
was: apparently, the Git repository is more like 100MB than 10MB and
that's only counting the non-archived issues, whereas when all the
issues were included the size was around 400MB.

This said, what's a factor 40x between friends, really?

So Tassilo's experiment with forge.el where he gets 200MB for 20K issues
in an sqlite database is actually in the same ballpark or even better.
Sorry 'bout the noise.


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Toon Claes]

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

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

> OK, I finally tracked down the disk where I kept this experiment.
> And indeed, I see that the past looks always much better than it really
> was: apparently, the Git repository is more like 100MB than 10MB and
> that's only counting the non-archived issues, whereas when all the
> issues were included the size was around 400MB.

To do some testing with GitLab on EMBA, I want to import a bunch of
issues from debbugs (preferably all). How did you extract the data from
debbugs? Or can you share the archive somewhere?

I've found a script [1] to load data from debbugs, but I don't want to
hammer the debbugs.gnu.org loading everything.

If you're interested, the POC script is here
https://gitlab.com/snippets/1856726/raw

-- 
Toon

[1] https://wiki.debian.org/DebbugsSoapInterface#Ruby

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

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

>> OK, I finally tracked down the disk where I kept this experiment.
>> And indeed, I see that the past looks always much better than it really
>> was: apparently, the Git repository is more like 100MB than 10MB and
>> that's only counting the non-archived issues, whereas when all the
>> issues were included the size was around 400MB.
> To do some testing with GitLab on EMBA, I want to import a bunch of
> issues from debbugs (preferably all).  How did you extract the data from
> debbugs? Or can you share the archive somewhere?

Glenn had opened an rsync access for me.

He can probably re-open it for you, but you can get the archive
I have (it's from 2015 so it's incomplete compared to what we have now,
but I don't think there's been much change qualitatively speaking) from:

    http://faina.iro.umontreal.ca/monnier/db-h.tar.lz
and
    http://faina.iro.umontreal.ca/monnier/archive.tar.lz

they're more or less 100MB resp. 180MB.

[ It's split into two because debbugs splits it into two (the "active"
  bugs and the "archived" bugs).  ]
  

        Stefan

Re: [OFFTOPIC] size of issue tracker

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Date: Wed, 15 May 2019 09:45:32 +0200
> Cc: emacs-devel@gnu.org
> 
> I've found a script [1] to load data from debbugs, but I don't want to
> hammer the debbugs.gnu.org loading everything.

Please note that we don't want all of debbugs, I think.  We want only
bugs related to Emacs.

Re: [OFFTOPIC] size of issue tracker

[Clemens Radermacher]

> One of the reasons why I really wish for a bug tracker that keeps the
> issues in Git (and no, sadly, BuGit is not up-to-the-task, it's just
> a 100KB proof-of-concept shell script).


I was just skimming through the thread and read about your wish for 
an issue tracker in git. I recently stumbled across https://github.com/MichaelMure/git-bug
which is GPL Licensed and might be of interest.
 


        Clemens

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

> I was just skimming through the thread and read about your wish for
> an issue tracker in git. I recently stumbled across
> https://github.com/MichaelMure/git-bug which is GPL Licensed and might
> be of interest.

Yes, it's a similar design to the one I used in BuGit.
For Emacs's use, it sadly doesn't have any email interface currently, so
it might not satisfy all the constraints yet.
But it's probably the most mature of the issue trackers that satisfy my
needs for off-line operation.


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Jean-Christophe Helary]

> On May 17, 2019, at 4:58, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> I was just skimming through the thread and read about your wish for
>> an issue tracker in git. I recently stumbled across
>> https://github.com/MichaelMure/git-bug which is GPL Licensed and might
>> be of interest.
> 
> Yes, it's a similar design to the one I used in BuGit.
> For Emacs's use, it sadly doesn't have any email interface currently, so
> it might not satisfy all the constraints yet.

I think sourcehut was referenced earlier in the thread.

https://man.sr.ht

It seems to be close to what is needed regarding a mail based workflow.

Jean-Christophe 

> But it's probably the most mature of the issue trackers that satisfy my
> needs for off-line operation.
> 
> 
>        Stefan
> 
> 

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

> I think sourcehut was referenced earlier in the thread.
> https://man.sr.ht
> It seems to be close to what is needed regarding a mail based workflow.

AFAIK it doesn't allow offline use (to clarify, offline use is
something I'd like to have, but is not something that's been mentioned
as needed to replace debbugs).


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Juri Linkov]

> I was just skimming through the thread and read about your wish for
> an issue tracker in git. I recently stumbled across https://github.com/MichaelMure/git-bug
> which is GPL Licensed and might be of interest.

Using Git to provide offline access is a nice feature, but I don't
understand why all data should be encoded in an internal format and
access to it to be hidden behind an indirection layer of command line
interface?  Why not to use plain text files?

For example, M-x report-emacs-bug could create a new Org file whose name
contains the current timestamp and a slugified summary, in a directory
of Org files, e.g. "issues/20190519_create_better_issue_tracker.org".
All metadata (like description, status, severity, tags, etc.)
could be added to the beginning of each Org file using Org keywords.
A list of issues is accessible by Dired, search using Rgrep, comments
organized in Wiki-like discussions, and archived issues moved
to the subdirectory "archived/".

Re: [OFFTOPIC] size of issue tracker

[Stefan Monnier]

> For example, M-x report-emacs-bug could create a new Org file whose name
> contains the current timestamp and a slugified summary, in a directory
> of Org files, e.g. "issues/20190519_create_better_issue_tracker.org".
> All metadata (like description, status, severity, tags, etc.)
> could be added to the beginning of each Org file using Org keywords.
> A list of issues is accessible by Dired, search using Rgrep, comments
> organized in Wiki-like discussions, and archived issues moved
> to the subdirectory "archived/".

Not sure what was the motivation for git-bug developers, but for BuGit
my motivation for not using plaintext files is that I didn't want to
have to deal with conflict resolution.
So each message is added as a "commit message".  That gives you conflict
resolution for free as well as threading for free.


        Stefan

Re: [OFFTOPIC] size of issue tracker

[Juri Linkov]

> Not sure what was the motivation for git-bug developers, but for BuGit
> my motivation for not using plaintext files is that I didn't want to
> have to deal with conflict resolution.
> So each message is added as a "commit message".  That gives you conflict
> resolution for free as well as threading for free.

Blockchain everywhere :)

Re: [OFFTOPIC] size of issue tracker

[Toon Claes]

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

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

> Not sure what was the motivation for git-bug developers, but for BuGit
> my motivation for not using plaintext files is that I didn't want to
> have to deal with conflict resolution.

What is this BuGit you keep talking about? I cannot seem to find it on
the interwebs?

-- 
Toon

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

Re: [OFFTOPIC] size of issue tracker

[Basil L. Contovounesios]

Toon Claes <toon@iotcl.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Not sure what was the motivation for git-bug developers, but for BuGit
>> my motivation for not using plaintext files is that I didn't want to
>> have to deal with conflict resolution.
>
> What is this BuGit you keep talking about? I cannot seem to find it on
> the interwebs?

It's a project of Stefan's:

https://gitlab.com/monnier/bugit/
https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control.git@gnu.org/

-- 
Basil

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 10.05.2019 12:49, Eli Zaretskii wrote:

> Note how you again start from a change, not from a report of some
> issue/bug.  As Emacs is a very old and stable project, most of our
> changes fix bugs, not add new features.  Therefore, use cases that
> begin with issues are much more important to the workflow and to
> assessing the utility of the tools.

Like I also described previously, GitLab provides extra features for 
code reviews, so it's often natural to describe them first (as a sales 
pitch, so to speak).

>> I understand. That's why I want to figure out whether we can add changes
>> to GitLab, so (almost) everything also can be done outside the
>> webbrowser, and from emacs. Or maybe build something like the debbugs
>> package for emacs.
> 
> Personally, I think an Emacs client is almost a must, if we want to
> consider something like GitLab seriously.

I think you're already expecting the hypothetical person to have debbugs 
installed and Gnus configured, and view the bug through the debbugs package.

Whereas a random user starts with staring at the (very bare-bones) bug 
report page in the browser.

> I didn't mean the commit itself, I meant Emacs sources in general.  I
> frequently need to look up source fragments and definitions of various
> macros and structs when I review a patch.  Since the browser have no
> idea where the sources are, and is not in general a good tool for
> viewing sources of a software project, it is much less helpful here.

You can always pull the branch with changes that a user proposed, it's 
not hard to automate, and switch to it (if you're not worried about it 
doing something untoward in your Emacs).

Most of the time, with smaller patches, you can just read them but still 
use Emacs to navigate inside the current version of the code, to get a 
decent understanding. That's my usual workflow, but maybe yours differs.

>> Probably the most complicated about the current bug tracker, at least
>> from irregular contributor's POV, is interacting to a existing bug:
>> Where do I send the email to? Who do I CC? How do I set In-Reply-To?
> 
> In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
> the defaults always DTRT.  You don't need to think about any of that.

Again, that already requires that the user is starting with an email.

Also: is GMail a "decent MUA"? I haven't used it for years, but it's the 
most popular MUA on the planet now. And that's a fact.

>> On debbugs, I also always forget how to use the control server
>> commands.
> 
> Having a need to use the control command is rare, so I don't think
> this is a serious disadvantage.

Rare to set the "found in" or "fixed in" versions? Or retitle a bug? Or 
reopen? Or assign it to somebody?

> Besides, tricky control commands will
> give you that with any tool.

That's simply not true. A good tool will make a certain set of commands 
easy.

>> GitLab fixes that by showing buttons for actions like
>> close/reopen/label/assign...
> 
> There are maybe 2 or 3 people in the Emacs project who use these
> actions, so I'm not sure why we should be so interested in them.

If they were easier to do, *I* would do them more often. How's that for 
an argument?

>> Yes, I tried to stress the importance of email too. I regret to hear the
>> email interface of GitLab didn't work for you. I'll have a look whether
>> I can suggest changes to make the "litter" configurable. But besides
>> from that, are there any other annoyances you've encountered so far?
> 
> I don't know.  If the email notifications can be configured to work
> reasonably well, and could be responded to by email, that might be
> enough to start a more serious evaluation of the workflow.

If you're saying that we don't change labels of reassign bugs often, how 
are occasional notifications for these actions a problem?

I've tried to recall whether I receive them as well at my day job (we 
use GitLab) and... at first, I thought I don't get them at all. Them I 
remembered that MR reassignment emails do get sent. It just happens very 
rarely. But if it happens, that's an important action, so I don't 
understand why you don't want to be notified (they can probably be 
configured anyway).

More importantly, one can easily *unsubscribe* from particular 
discussions. For instance, when the bug been forwarded to somebody who 
has all the necessary expertise and responsibility. That can cut down on 
email traffic quite a bit.

>>> And one more thing: Emacs is I think special in how we work as a
>>> team.  Most of the people who respond to bug report and review patches
>>> have write access to the repository, and many of them are trusted to
>>> push changes without approval.  It sounds like Gitlab has a very
>>> different team organization in mind, but maybe I'm mistaken.

At work, we all have commit/push access to the project repositories.

And yet, the Merge Request workflow is still helpful, and it's what we 
use to collaborate, discuss and push most features.

We could consider being able to access MR from people without commit 
access as a bonus.

But the workflow is not set in stone, we as Emacs developers can choose 
our own.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, agrambot@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 10 May 2019 14:16:30 +0300
> 
> On 10.05.2019 12:49, Eli Zaretskii wrote:
> 
> > Personally, I think an Emacs client is almost a must, if we want to
> > consider something like GitLab seriously.
> 
> I think you're already expecting the hypothetical person to have debbugs 
> installed and Gnus configured, and view the bug through the debbugs package.

No, because the current flow is email-based, so having an email client
is 80% enough.

> > I didn't mean the commit itself, I meant Emacs sources in general.  I
> > frequently need to look up source fragments and definitions of various
> > macros and structs when I review a patch.  Since the browser have no
> > idea where the sources are, and is not in general a good tool for
> > viewing sources of a software project, it is much less helpful here.
> 
> You can always pull the branch with changes that a user proposed

I think this is a misunderstanding, I wasn't talking about the patches
at all, I was talking about the rest of the sources.  I tried to
explain that above.  As an example, suppose a patch touches some
function or variable, and I want to see how that function/variable is
used in Emacs.

> >> Probably the most complicated about the current bug tracker, at least
> >> from irregular contributor's POV, is interacting to a existing bug:
> >> Where do I send the email to? Who do I CC? How do I set In-Reply-To?
> > 
> > In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
> > the defaults always DTRT.  You don't need to think about any of that.
> 
> Again, that already requires that the user is starting with an email.

The original question was clearly about doing this via email.

> Also: is GMail a "decent MUA"? I haven't used it for years, but it's the 
> most popular MUA on the planet now. And that's a fact.

If you mean the decision whether to click "Reply" or "Reply all" in
the Gmail UI, then yes, the user will have to learn to click the
latter.  If that's a burden, then I guess Gmail is not "reasonable".

> >> On debbugs, I also always forget how to use the control server
> >> commands.
> > 
> > Having a need to use the control command is rare, so I don't think
> > this is a serious disadvantage.
> 
> Rare to set the "found in" or "fixed in" versions? Or retitle a bug? Or 
> reopen? Or assign it to somebody?

Yes, all of the above.  Just look at how much these are used in Emacs.

> > Besides, tricky control commands will
> > give you that with any tool.
> 
> That's simply not true. A good tool will make a certain set of commands 
> easy.

I guess we have different experiences about that.

> >> GitLab fixes that by showing buttons for actions like
> >> close/reopen/label/assign...
> > 
> > There are maybe 2 or 3 people in the Emacs project who use these
> > actions, so I'm not sure why we should be so interested in them.
> 
> If they were easier to do, *I* would do them more often.

What for?  Why would you need to do that?

> > I don't know.  If the email notifications can be configured to work
> > reasonably well, and could be responded to by email, that might be
> > enough to start a more serious evaluation of the workflow.
> 
> If you're saying that we don't change labels of reassign bugs often, how 
> are occasional notifications for these actions a problem?

Who are "we"?  The few people who do that tend to do it quite a lot.
And every bug is closed, which also causes a useless notification.
And when a patch is posted, I get another useless notification.
Etc. etc.

> I've tried to recall whether I receive them as well at my day job (we 
> use GitLab) and... at first, I thought I don't get them at all. Them I 
> remembered that MR reassignment emails do get sent. It just happens very 
> rarely. But if it happens, that's an important action, so I don't 
> understand why you don't want to be notified (they can probably be 
> configured anyway).

MR reassignments are important to just 2 people: the old and the new
assignee, possibly just the latter.  I certainly don't want to know
about all the reassignments of all the issues.  On the rare occasion
that I do need to see that, I will gladly use a special UI for
browsing the history of an issue in some way, but that happens very
rarely, at least to me.

> More importantly, one can easily *unsubscribe* from particular 
> discussions. For instance, when the bug been forwarded to somebody who 
> has all the necessary expertise and responsibility. That can cut down on 
> email traffic quite a bit.

In my position, I don't think I will be able to unsubscribe, so this
is not a good option for someone who wants to read most of the
issue-related traffic.  People who do the triage are like that, for
example.

> >>> And one more thing: Emacs is I think special in how we work as a
> >>> team.  Most of the people who respond to bug report and review patches
> >>> have write access to the repository, and many of them are trusted to
> >>> push changes without approval.  It sounds like Gitlab has a very
> >>> different team organization in mind, but maybe I'm mistaken.
> 
> At work, we all have commit/push access to the project repositories.
> 
> And yet, the Merge Request workflow is still helpful, and it's what we 
> use to collaborate, discuss and push most features.
> 
> We could consider being able to access MR from people without commit 
> access as a bonus.
> 
> But the workflow is not set in stone, we as Emacs developers can choose 
> our own.

I understand, but that doesn't address my concerns.  However, this
particular aspect of GitLab is not a major one, I guess we will see
when we get to that.

Thanks.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 10.05.2019 15:54, Eli Zaretskii wrote:

>> I think you're already expecting the hypothetical person to have debbugs
>> installed and Gnus configured, and view the bug through the debbugs package.
> 
> No, because the current flow is email-based, so having an email client
> is 80% enough.

Recall the original question: "Where do I send the email to? Who do I 
CC? How do I set In-Reply-To?"

Simply having an email client doesn't answer any of these questions. You 
first need an email to respond to. And that's basically limited to the 
"inner circle" of Emacs developers who are already subscribed to the bug 
tracker emails.

> I think this is a misunderstanding,

Probably.

> I wasn't talking about the patches
> at all, I was talking about the rest of the sources.  I tried to
> explain that above.  As an example, suppose a patch touches some
> function or variable, and I want to see how that function/variable is
> used in Emacs.

I open Emacs. It's usually one or two Alt-Tab's away, a much quicker 
interaction that what most things that have to do with the bug tracker 
require of me.

>>>> Probably the most complicated about the current bug tracker, at least
>>>> from irregular contributor's POV, is interacting to a existing bug:
>>>> Where do I send the email to? Who do I CC? How do I set In-Reply-To?
>>>
>>> In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
>>> the defaults always DTRT.  You don't need to think about any of that.
>>
>> Again, that already requires that the user is starting with an email.
> 
> The original question was clearly about doing this via email.

No, it was about how a user can interact with a bug report. But since 
email is the only option, of course it enumerated the details one has to 
get right to write the said email.

>> Also: is GMail a "decent MUA"? I haven't used it for years, but it's the
>> most popular MUA on the planet now. And that's a fact.
> 
> If you mean the decision whether to click "Reply" or "Reply all" in
> the Gmail UI, then yes, the user will have to learn to click the
> latter.  If that's a burden, then I guess Gmail is not "reasonable".

You can surely remember yourself that every once in a while somebody 
clicks "Reply" instead of "Reply All", because it's an easy mistake to make.

But see above, the question is not about which of these two buttons to 
choose.

>>>> On debbugs, I also always forget how to use the control server
>>>> commands.
>>>
>>> Having a need to use the control command is rare, so I don't think
>>> this is a serious disadvantage.
>>
>> Rare to set the "found in" or "fixed in" versions? Or retitle a bug? Or
>> reopen? Or assign it to somebody?
> 
> Yes, all of the above.  Just look at how much these are used in Emacs.

Not nearly enough. Especially if we're talking about "fixed in". 
Retitling is also helpful when used judiciously.

>>> Besides, tricky control commands will
>>> give you that with any tool.
>>
>> That's simply not true. A good tool will make a certain set of commands
>> easy.
> 
> I guess we have different experiences about that.

I'm pretty sure you have seen a web UI for GitHub or GitLab. "Close 
issue", or "reopen issue", or "set label" are only a mouse click away, 
and you don't have to search the Control Server documentation to figure 
out how to do either.

>>>> GitLab fixes that by showing buttons for actions like
>>>> close/reopen/label/assign...
>>>
>>> There are maybe 2 or 3 people in the Emacs project who use these
>>> actions, so I'm not sure why we should be so interested in them.
>>
>> If they were easier to do, *I* would do them more often.
> 
> What for?  Why would you need to do that?

For instance, to assign a bug to somebody who is not subscribed to all 
bug reports, but who I know is knowledgeable in the subject.

Thankfully, I remember how to close a bug or set the "fixed in" header, 
but if I forgot to add that header while closing, adding "fixed in" 
later is not so easy. Reopening bugs is not easy either.

>>> I don't know.  If the email notifications can be configured to work
>>> reasonably well, and could be responded to by email, that might be
>>> enough to start a more serious evaluation of the workflow.
>>
>> If you're saying that we don't change labels of reassign bugs often, how
>> are occasional notifications for these actions a problem?
> 
> Who are "we"?  The few people who do that tend to do it quite a lot.

We as Emacs developers. But if you're saying it's okay that only a 
handful of people ever do that... OK.

> And every bug is closed, which also causes a useless notification.

You mean the ones Debbugs sends? I've never considered that much of a 
problem. But at least GitLab can't be worse in that respect.

Also: if I myself closed the bug, GitLab wouldn't send the notification 
to me (that would be extraneous).

> And when a patch is posted, I get another useless notification.

Sorry, you lost me here. Don't you expect to be notified for every 
message in the bug tracker?

>> I've tried to recall whether I receive them as well at my day job (we
>> use GitLab) and... at first, I thought I don't get them at all. Them I
>> remembered that MR reassignment emails do get sent. It just happens very
>> rarely. But if it happens, that's an important action, so I don't
>> understand why you don't want to be notified (they can probably be
>> configured anyway).
> 
> MR reassignments are important to just 2 people: the old and the new
> assignee, possibly just the latter.  I certainly don't want to know
> about all the reassignments of all the issues.

I don't know if I agree, but hopefully it can be configured this way.

If the email workflow is used, though, you can also do what I've seen 
many people recommend to others who complained about excessive emails 
here (or being Cc'd on discussions they do not want to read, which is 
more of a problem, IMHO): set up email filters. Decent MUAs support that.

>> More importantly, one can easily *unsubscribe* from particular
>> discussions. For instance, when the bug been forwarded to somebody who
>> has all the necessary expertise and responsibility. That can cut down on
>> email traffic quite a bit.
> 
> In my position, I don't think I will be able to unsubscribe, so this
> is not a good option for someone who wants to read most of the
> issue-related traffic.  People who do the triage are like that, for
> example.

That might make contributing more comfortable for some others, though, 
which is still a plus.

> I understand, but that doesn't address my concerns.  However, this
> particular aspect of GitLab is not a major one, I guess we will see
> when we get to that.

Whenever you feel like it, we can go ahead and experiment with the bug 
tracker that's part of the EMBA installation. And see how far we can go 
with email-only workflow, without an Emacs-based client.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  agrambot@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 10 May 2019 16:56:02 +0300
> 
> On 10.05.2019 15:54, Eli Zaretskii wrote:
> 
> >> I think you're already expecting the hypothetical person to have debbugs
> >> installed and Gnus configured, and view the bug through the debbugs package.
> > 
> > No, because the current flow is email-based, so having an email client
> > is 80% enough.
> 
> Recall the original question: "Where do I send the email to? Who do I 
> CC? How do I set In-Reply-To?"

Which I already answered.

> > I wasn't talking about the patches
> > at all, I was talking about the rest of the sources.  I tried to
> > explain that above.  As an example, suppose a patch touches some
> > function or variable, and I want to see how that function/variable is
> > used in Emacs.
> 
> I open Emacs. It's usually one or two Alt-Tab's away, a much quicker 
> interaction that what most things that have to do with the bug tracker 
> require of me.

Yes, my point was that having to work via a Web browser will need to
switch frequently between it and Emacs.  Which is an annoyance, to say
the least.

> >>>> Probably the most complicated about the current bug tracker, at least
> >>>> from irregular contributor's POV, is interacting to a existing bug:
> >>>> Where do I send the email to? Who do I CC? How do I set In-Reply-To?
> >>>
> >>> In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
> >>> the defaults always DTRT.  You don't need to think about any of that.
> >>
> >> Again, that already requires that the user is starting with an email.
> > 
> > The original question was clearly about doing this via email.
> 
> No, it was about how a user can interact with a bug report.

You can interpret it as you like, but questions regarding CC and
In-Reply-To don't make sense in any context but email.

> > If you mean the decision whether to click "Reply" or "Reply all" in
> > the Gmail UI, then yes, the user will have to learn to click the
> > latter.  If that's a burden, then I guess Gmail is not "reasonable".
> 
> You can surely remember yourself that every once in a while somebody 
> clicks "Reply" instead of "Reply All", because it's an easy mistake to make.

Not so easy, as most people do manage to DTRT.

> > And every bug is closed, which also causes a useless notification.
> 
> You mean the ones Debbugs sends? I've never considered that much of a 
> problem. But at least GitLab can't be worse in that respect.

It's worse, because debbugs doesn't send me notifications of closing
bugs, except when I close them, or when I was the one who filed the
bug.

> > And when a patch is posted, I get another useless notification.
> 
> Sorry, you lost me here. Don't you expect to be notified for every 
> message in the bug tracker?

Only once, yes.  I don't want notifications about the attributes of
the new bug being set as side effect of accepting it.

> > MR reassignments are important to just 2 people: the old and the new
> > assignee, possibly just the latter.  I certainly don't want to know
> > about all the reassignments of all the issues.
> 
> I don't know if I agree, but hopefully it can be configured this way.

I hoped someone will explain how.  No one did.

> If the email workflow is used, though, you can also do what I've seen 
> many people recommend to others who complained about excessive emails 
> here (or being Cc'd on discussions they do not want to read, which is 
> more of a problem, IMHO): set up email filters. Decent MUAs support that.

Email filters are the last resort in my book.  It would also be in
yours, if you considered a possibility to work via email.

Once again, if you want to make a change in our workflow, please make
sure the change doesn't raise the bar for the core developers too
much, or else it will be a hard sell.

> >> More importantly, one can easily *unsubscribe* from particular
> >> discussions. For instance, when the bug been forwarded to somebody who
> >> has all the necessary expertise and responsibility. That can cut down on
> >> email traffic quite a bit.
> > 
> > In my position, I don't think I will be able to unsubscribe, so this
> > is not a good option for someone who wants to read most of the
> > issue-related traffic.  People who do the triage are like that, for
> > example.
> 
> That might make contributing more comfortable for some others, though, 
> which is still a plus.

Not what was being discussed.

> > I understand, but that doesn't address my concerns.  However, this
> > particular aspect of GitLab is not a major one, I guess we will see
> > when we get to that.
> 
> Whenever you feel like it, we can go ahead and experiment with the bug 
> tracker that's part of the EMBA installation. And see how far we can go 
> with email-only workflow, without an Emacs-based client.

I don't think I understand what such an experiment would mean.  Do you
mean we will have to deal with each bug twice?  And what would be the
workflow in that case? can someone post some instructions?

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Fri, May 10, 2019 at 4:20 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> >  agrambot@gmail.com
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Fri, 10 May 2019 16:56:02 +0300
> >
> > On 10.05.2019 15:54, Eli Zaretskii wrote:
> > > If you mean the decision whether to click "Reply" or "Reply all" in
> > > the Gmail UI, then yes, the user will have to learn to click the
> > > latter.  If that's a burden, then I guess Gmail is not "reasonable".
> >
> > You can surely remember yourself that every once in a while somebody
> > clicks "Reply" instead of "Reply All", because it's an easy mistake to make.
>
> Not so easy, as most people do manage to DTRT.

Gmail can be configured to default to "Reply All".

-- 
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[Óscar Fuentes]

Tadeus Prastowo <tadeus.prastowo@unitn.it> writes:

>> > > If you mean the decision whether to click "Reply" or "Reply all" in
>> > > the Gmail UI, then yes, the user will have to learn to click the
>> > > latter.  If that's a burden, then I guess Gmail is not "reasonable".
>> >
>> > You can surely remember yourself that every once in a while somebody
>> > clicks "Reply" instead of "Reply All", because it's an easy mistake to make.
>>
>> Not so easy, as most people do manage to DTRT.
>
> Gmail can be configured to default to "Reply All".

Asking people to change their MUA defaults just to comply with Emacs'
bug tracker requirements is not realistic.

Re: [RFE] Migration to gitlab

[Tadeus Prastowo]

On Fri, May 10, 2019 at 5:00 PM Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> Tadeus Prastowo <tadeus.prastowo@unitn.it> writes:
>
> >> > > If you mean the decision whether to click "Reply" or "Reply all" in
> >> > > the Gmail UI, then yes, the user will have to learn to click the
> >> > > latter.  If that's a burden, then I guess Gmail is not "reasonable".
> >> >
> >> > You can surely remember yourself that every once in a while somebody
> >> > clicks "Reply" instead of "Reply All", because it's an easy mistake to make.
> >>
> >> Not so easy, as most people do manage to DTRT.
> >
> > Gmail can be configured to default to "Reply All".
>
> Asking people to change their MUA defaults just to comply with Emacs'
> bug tracker requirements is not realistic.

In my experience, regardless of MUA and Emacs, defaulting to "Reply
All" is better than not.

-- 
Best regards,
Tadeus

Re: [RFE] Migration to gitlab

[조성빈]

> 2019. 5. 10. 오후 11:19, Eli Zaretskii <eliz@gnu.org> 작성:
> 
>>> I wasn't talking about the patches
>>> at all, I was talking about the rest of the sources.  I tried to
>>> explain that above.  As an example, suppose a patch touches some
>>> function or variable, and I want to see how that function/variable is
>>> used in Emacs.
>> 
>> I open Emacs. It's usually one or two Alt-Tab's away, a much quicker 
>> interaction that what most things that have to do with the bug tracker 
>> require of me.
> 
> Yes, my point was that having to work via a Web browser will need to
> switch frequently between it and Emacs.  Which is an annoyance, to say
> the least.

> github.com/magit/forge

Re: [RFE] Migration to gitlab

[Clément Pit-Claudel]

On 2019-05-10 11:00, 조성빈 wrote:
>> github.com/magit/forge

Forge is great, but we should evaluate it carefully before deciding that we want to depend on it.  Concretely, about a week ago, Eli wrote and asked how one could browse Gitlab issues from Emacs, e.g. the issue that Toon had created on the Gitlab repo about Emacs' needs.

I set out to write detailed instructions, but gave up halfway, because forge didn't work for that use case.  Indeed, the way forge deals with issues and merge requests is to download the full issue database of the project.  For Gitlab, with 27000 merge requests and 50000 issues, the software spent multiple of minutes attempting to download this humongous database, and then gave up and threw an exception.  Accordingly, I gave up and didn't post my instructions (Eli, they are below, if you are curious to try them on a smaller repository; forge is indeed great when it can handle the repo size).

I do not know whether Emacs' issue database is large enough to cause issues. Additionally, I understand that thigs may improve in the future, because forge currently uses an inefficient communication protocol to talk to Gitlab (but there are plans to support a better protocol in Gitlab, I think).  I do not know whether things will work better once Gitlab implements a better protocol (I hope they will!).  In the meantime, we should be careful about assuming that forge will solve the problem of browsing Gitlab issues from Emacs.

Below are the instructions I had started to write.

Clément.

On 2019-04-30 11:37, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 30 Apr 2019 00:35:11 +0300
>> Cc: emacs-devel <emacs-devel@gnu.org>
>>
>> Speaking of GitLab clients, here's one: 
>> https://github.com/nlamirault/emacs-gitlab
>>
>> I haven't tried it myself yet, but it seems to include commenting 
>> functionality (gitlab-notes.el).
>
> Does anyone know how to use that to browse some GitLab issue, e.g. the
> one posted by Toon?  I tried to do that, but got only error messages.
> I suspect that I didn't understand how to use the package.

I haven't tried this particular package, but here is how to do it using magit and forge:

* Gitlab authentication:
  * Browse to https://gitlab.com/profile/personal_access_tokens ; check the 'api' box and give a name to the token (e.g. Emacs Forge) ; click 'Create personal access token'
  * Copy the resulting token into ~/.authinfo, on a new line like the following (make sure there is a final newline at the end of the file):
    machine gitlab.com/api/v4 login YOUR_GITLAB_USERNAME^forge password YOUR_TOKEN
  * Set your username: git config gitlab.user YOUR_GITLAB_USERNAME
  * Clone the gitlab-ce repository: git clone https://gitlab.com/gitlab-org/gitlab-ce.git/ --depth 1 SOMEWHERE_CONVENIENT
* Emacs setup:
  * Add MELPA to your package repositories: (add-to-list 'package-archives (cons "melpa" "https://melpa.org/packages/") t)
  * M-x package-list-packages; install 'magit' and 'forge'
  * C-u M-x magit-status; type the directory (SOMEWHERE_CONVENIENT) in which you cloned the repository above
  * M-: (require 'forge); then press f y (This retrieves the full collection of merge requests and bug reports for that repository; it fails, because gitlab-ce has 50000 issues and 27000 merge requests).
  * Once this completes, you have access in the `magit' buffer to a list of issues and merge requests; you press RET on any of them to view the discussion.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  agrambot@gmail.com, Dmitry Gutov <dgutov@yandex.ru>
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 10 May 2019 11:26:55 -0400
> 
> I set out to write detailed instructions, but gave up halfway, because forge didn't work for that use case.  Indeed, the way forge deals with issues and merge requests is to download the full issue database of the project.  For Gitlab, with 27000 merge requests and 50000 issues, the software spent multiple of minutes attempting to download this humongous database, and then gave up and threw an exception.  Accordingly, I gave up and didn't post my instructions (Eli, they are below, if you are curious to try them on a smaller repository; forge is indeed great when it can handle the repo size).
> 
> I do not know whether Emacs' issue database is large enough to cause issues. Additionally, I understand that thigs may improve in the future, because forge currently uses an inefficient communication protocol to talk to Gitlab (but there are plans to support a better protocol in Gitlab, I think).  I do not know whether things will work better once Gitlab implements a better protocol (I hope they will!).  In the meantime, we should be careful about assuming that forge will solve the problem of browsing Gitlab issues from Emacs.
> 
> Below are the instructions I had started to write.

Thank you very much for your efforts.

Is there any way of knowing at what number of issues for forge choke
when downloading the database?  We have a good idea of how many issues
we have in ours, so we could figure out if this problem will be of any
concern.

Re: [RFE] Migration to gitlab

[Clément Pit-Claudel]

On 2019-05-11 08:13, Eli Zaretskii wrote:
> Is there any way of knowing at what number of issues for forge choke
> when downloading the database?  We have a good idea of how many issues
> we have in ours, so we could figure out if this problem will be of any
> concern.

I opened a bug report on the ghub tracker to ask about this (ghub is the library that forge uses to talk to Gitlab).

Clément.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: pcr910303@icloud.com, toon@iotcl.com, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca, agrambot@gmail.com, dgutov@yandex.ru
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 11 May 2019 11:37:27 -0400
> 
> On 2019-05-11 08:13, Eli Zaretskii wrote:
> > Is there any way of knowing at what number of issues for forge choke
> > when downloading the database?  We have a good idea of how many issues
> > we have in ours, so we could figure out if this problem will be of any
> > concern.
> 
> I opened a bug report on the ghub tracker to ask about this (ghub is the library that forge uses to talk to Gitlab).

I hoped that maybe it was providing some indication of how many issues
were processed, by the time it crashed.  But I guess not?

Re: [RFE] Migration to gitlab

[Clément Pit-Claudel]

On 2019-05-11 11:51, Eli Zaretskii wrote:
>> Cc: pcr910303@icloud.com, toon@iotcl.com, emacs-devel@gnu.org,
>>  monnier@iro.umontreal.ca, agrambot@gmail.com, dgutov@yandex.ru
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Sat, 11 May 2019 11:37:27 -0400
>>
>> On 2019-05-11 08:13, Eli Zaretskii wrote:
>>> Is there any way of knowing at what number of issues for forge choke
>>> when downloading the database?  We have a good idea of how many issues
>>> we have in ours, so we could figure out if this problem will be of any
>>> concern.
>>
>> I opened a bug report on the ghub tracker to ask about this (ghub is the library that forge uses to talk to Gitlab).
> 
> I hoped that maybe it was providing some indication of how many issues
> were processed, by the time it crashed.  But I guess not?

No, unfortunately not.

Re: [RFE] Migration to gitlab

[Toon Claes]

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

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

> I opened a bug report on the ghub tracker to ask about this (ghub is
> the library that forge uses to talk to Gitlab).

For completeness, here the link:

https://github.com/magit/ghub/issues/87

I've asked whether we'd need GraphQL support on GitLab to overcome the
performance issue. I think this is the _better protocol_ Clément
mentioned earlier. Forge uses it for GitHub already, but not for GitLab,
cause it's not fully supported by GitLab yet.


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 10.05.2019 17:19, Eli Zaretskii wrote:

> Yes, my point was that having to work via a Web browser will need to
> switch frequently between it and Emacs.  Which is an annoyance, to say
> the least.

I can believe that, even if I don't really understand it.

Anyway, IIRC your current stance on that issue is that we'll need an 
Emacs-based client anyway, even just for the issues tracker.

> It's worse, because debbugs doesn't send me notifications of closing
> bugs, except when I close them, or when I was the one who filed the
> bug.

Hmm. Let's see if it can be configured as well, or we can add that to 
the list of requirements on the GitLab-CE issue Toon opened.

>>> And when a patch is posted, I get another useless notification.
>>
>> Sorry, you lost me here. Don't you expect to be notified for every
>> message in the bug tracker?
> 
> Only once, yes.  I don't want notifications about the attributes of
> the new bug being set as side effect of accepting it.

Same as above.

>>> MR reassignments are important to just 2 people: the old and the new
>>> assignee, possibly just the latter.  I certainly don't want to know
>>> about all the reassignments of all the issues.
>>
>> I don't know if I agree, but hopefully it can be configured this way.
> 
> I hoped someone will explain how.  No one did.

If you log into EMBA (you might have to register first (*)) and navigate 
to this page: https://emba.gnu.org/profile/notifications

you will see two "notification level" dropdowns, one Global, and one for 
'emacs'. I think you can change either.

Click on one of them and choose the last item: Custom. You will then be 
able to choose the events to get notifications for.

MR reassignments are in that list.

Here's also the same information on the API level: 
https://docs.gitlab.com/ee/api/notification_settings.html

Not sure if that list is exhaustive, or if there are emails we'd want to 
configure off but cannot. That would, again, be something to ask the 
GitLab developers for.

>> If the email workflow is used, though, you can also do what I've seen
>> many people recommend to others who complained about excessive emails
>> here (or being Cc'd on discussions they do not want to read, which is
>> more of a problem, IMHO): set up email filters. Decent MUAs support that.
> 
> Email filters are the last resort in my book.  It would also be in
> yours, if you considered a possibility to work via email.

But I already do, here.

> Once again, if you want to make a change in our workflow, please make
> sure the change doesn't raise the bar for the core developers too
> much, or else it will be a hard sell.

I try.

>> Whenever you feel like it, we can go ahead and experiment with the bug
>> tracker that's part of the EMBA installation. And see how far we can go
>> with email-only workflow, without an Emacs-based client.
> 
> I don't think I understand what such an experiment would mean.  Do you
> mean we will have to deal with each bug twice?  And what would be the
> workflow in that case? can someone post some instructions?

No, I'm suggesting to use it as a sandbox at first. Post some random 
issues, close them, reopen them, write some comments, receive comments 
from others, respond to them over email, etc, and see how well that 
works, and what the main problems are.

To post a new issue, you can navigate to 
https://emba.gnu.org/emacs/emacs/issues and click "New issue". This also 
requires registration (at least, for now (**)).

(*) I think currently registration is only manual, so we'll need to ask 
Toon to create an account.

(**) IIUC later we can configure it to allow logging in with existing 
Google/Twitter/etc accounts, and, with some work, even authenticate with 
Savannah 
(https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/integration/omniauth.md).

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  agrambot@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 10 May 2019 19:33:56 +0300
> 
> On 10.05.2019 17:19, Eli Zaretskii wrote:
> 
> > Yes, my point was that having to work via a Web browser will need to
> > switch frequently between it and Emacs.  Which is an annoyance, to say
> > the least.
> 
> I can believe that, even if I don't really understand it.

Let me try to explain.

In any editing environment that is not Emacs I lack many features that
make my work significantly more efficient.  I miss the almost instant
completion with M-/ (since I have the Emacs manuals and the TAGS
tables loaded into Emacs at all times, all the symbols are instantly
found, and I seldom if ever need to type long names like
mark_window_display_accurate_1).  I miss my abbrevs (which also allow
me to fix some of my more frequent typos, or type stuff like "naïve" o
"façade" without switching keyboard).  I miss the convenience of being
able to jump to any function/macro/typedef with just "C-u M-."  (or
even just M-. if I'm in a code buffer).  I miss the multi-buffer
search capabilities and Grep.  I miss a more-or-less immediate access
to the Git repository.  I miss the capability to apply a patch which
I'm looking at, and be able to compile the result right after that,
right from the editor.

And these are just the tools I use almost all the time.

Instead, GitLab wants me to use the Web browser for most of these.
This means the Web browser now becomes a very important program for
me, I need to start learning it much more than I bothered until now, I
need to keep it updated at all times, I need to customize it (more
things to learn and try), etc.  And after all that I still get an
abysmally inadequate text editing widget, lacking most if not all of
the features I mentioned above, while for tasks other than
writing/editing text you ask me to switch between the browser and
Emacs.  That's a massive degradation of my quality of life.

I wonder if I'm the only one here who feels that way.  I mean, one of
the more important advantages of Emacs is that it lets you do many
things only tangentially related to editing program sources, and now
we suddenly are willing to give that up?  Really??

> Anyway, IIRC your current stance on that issue is that we'll need an 
> Emacs-based client anyway, even just for the issues tracker.

I don't have a "stance".  My personal preference is to do as much as
possible from within Emacs, certainly any significant text/source code
editing related to Emacs maintenance.  I would be very unhappy if
forced instead to use a text-editing widget of a browser, and its
rudimentary email capabilities.

Two possible ways of working with an issue tracker that don't require
me to switch from Emacs are: (1) email and (2) an Emacs front-end.
Either one, or even a combination of them, will, for me, be much
better than a pure Web UI.

I'm very interested in hearing opinions of other core maintainers and
developers.

> >>> MR reassignments are important to just 2 people: the old and the new
> >>> assignee, possibly just the latter.  I certainly don't want to know
> >>> about all the reassignments of all the issues.
> >>
> >> I don't know if I agree, but hopefully it can be configured this way.
> > 
> > I hoped someone will explain how.  No one did.
> 
> If you log into EMBA (you might have to register first (*)) and navigate 
> to this page: https://emba.gnu.org/profile/notifications
> 
> you will see two "notification level" dropdowns, one Global, and one for 
> 'emacs'. I think you can change either.
> 
> Click on one of them and choose the last item: Custom. You will then be 
> able to choose the events to get notifications for.
> 
> MR reassignments are in that list.

I cannot see it, because I cannot log in.  Are there only 2
possibilities: all or nothing?  I do want to see reassignments to
myself.

> Here's also the same information on the API level: 
> https://docs.gitlab.com/ee/api/notification_settings.html

Where is each value described?  The names are not descriptive enough,
and I couldn't find any details about them.  Did I miss something?

> Not sure if that list is exhaustive, or if there are emails we'd want to 
> configure off but cannot. That would, again, be something to ask the 
> GitLab developers for.

If there's no more detailed documentation, I think we should ask them
now what does exist and what is possible to have given some small
effort.

> >> If the email workflow is used, though, you can also do what I've seen
> >> many people recommend to others who complained about excessive emails
> >> here (or being Cc'd on discussions they do not want to read, which is
> >> more of a problem, IMHO): set up email filters. Decent MUAs support that.
> > 
> > Email filters are the last resort in my book.  It would also be in
> > yours, if you considered a possibility to work via email.
> 
> But I already do, here.

I never needed to set up any filters.  Never.  It sounds very wrong to
me that I need to set up a filter to defend myself against my own
project.

> >> Whenever you feel like it, we can go ahead and experiment with the bug
> >> tracker that's part of the EMBA installation. And see how far we can go
> >> with email-only workflow, without an Emacs-based client.
> > 
> > I don't think I understand what such an experiment would mean.  Do you
> > mean we will have to deal with each bug twice?  And what would be the
> > workflow in that case? can someone post some instructions?
> 
> No, I'm suggesting to use it as a sandbox at first. Post some random 
> issues, close them, reopen them, write some comments, receive comments 
> from others, respond to them over email, etc, and see how well that 
> works, and what the main problems are.
> 
> To post a new issue, you can navigate to 
> https://emba.gnu.org/emacs/emacs/issues and click "New issue". This also 
> requires registration (at least, for now (**)).

I will try to find time for this, but it won't happen soon: there are
several urgent tasks on my plate.  Perhaps someone else could do that
and post the experiences.

Thanks.

Re: [RFE] Migration to gitlab

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> I wonder if I'm the only one here who feels that way.  I mean, one of
> the more important advantages of Emacs is that it lets you do many
> things only tangentially related to editing program sources, and now
> we suddenly are willing to give that up?  Really??

No, you are not the only one that feels that way. Me too. And Alan...

It is possible to use Emacs to write text areas on web pages with an
extension. You enter the text area and with a key combination (1)
emacsclient is invoked. Those of us that are mouse-averse can use
extensions that make possible to click links, buttons, etc using the
keyboard, it is much more efficient than the mouse. There are more
possibilities to make the web less painful, it is just a matter of
installing two or three extensions and that takes no time if someone (2)
points you to the right place.

That said, the browser experience still lacks conveniences that we take
for granted, but also brings possibilities that are far from trivial to
implement on a pure Emacs UI, not to mention the backend
infraestructure. All things considered, for me, personally, is just
bearable. However, there is no doubt that nowadays there is no doubt
that a web-based UI is far more friendly and welcoming than something
like debbugs. This is something that we should put on the balance.

1. I seem to recall that there are extensions that does the thing
automatically, either inconditionally or depending on certain
conditions.

2. Me, for example.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 10 May 2019 23:12:08 +0200
> 
> It is possible to use Emacs to write text areas on web pages with an
> extension. You enter the text area and with a key combination (1)
> emacsclient is invoked. Those of us that are mouse-averse can use
> extensions that make possible to click links, buttons, etc using the
> keyboard, it is much more efficient than the mouse. There are more
> possibilities to make the web less painful, it is just a matter of
> installing two or three extensions and that takes no time if someone (2)
> points you to the right place.

With which browsers is this possible?  Any further details about such
extensions?

Thanks.

Re: [RFE] Migration to gitlab

[조성빈]

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

https://www.emacswiki.org/emacs/Edit_with_Emacs

나의 iPhone에서 보냄

2019. 5. 11. 오후 3:13, Eli Zaretskii <eliz@gnu.org> 작성:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Fri, 10 May 2019 23:12:08 +0200
>> 
>> It is possible to use Emacs to write text areas on web pages with an
>> extension. You enter the text area and with a key combination (1)
>> emacsclient is invoked. Those of us that are mouse-averse can use
>> extensions that make possible to click links, buttons, etc using the
>> keyboard, it is much more efficient than the mouse. There are more
>> possibilities to make the web less painful, it is just a matter of
>> installing two or three extensions and that takes no time if someone (2)
>> points you to the right place.
> 
> With which browsers is this possible?  Any further details about such
> extensions?
> 
> Thanks.
> 

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

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Sat, 11 May 2019 15:16:01 +0900
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
>  With which browsers is this possible?  Any further details about such
>  extensions?
> 
> https://www.emacswiki.org/emacs/Edit_with_Emacs

Thanks.  The answer seems to be "Google Chrome".  Unfortunately.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 11.05.2019 15:16, Eli Zaretskii wrote:
> The answer seems to be "Google Chrome".  Unfortunately.

Not necessarily:

https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 11 May 2019 15:34:19 +0300
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> On 11.05.2019 15:16, Eli Zaretskii wrote:
> > The answer seems to be "Google Chrome".  Unfortunately.
> 
> Not necessarily:
> 
> https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/

Much better, thanks.

Re: [RFE] Migration to gitlab

[Amin Bandali]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 11 May 2019 15:34:19 +0300
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>> 
>> On 11.05.2019 15:16, Eli Zaretskii wrote:
>> > The answer seems to be "Google Chrome".  Unfortunately.
>> 
>> Not necessarily:
>> 
>> https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/
>
> Much better, thanks.
>

You could also go for something like Tridactyl [0], which allows you to
accomplish various tasks using only your keyboard.  The default bindings
are modelled after Vim, but it’s very malleable and you could change
(almost) every binding.  I say almost because in recent versions of
Firefox (and by extension IceCat) you can’t rebind some of the “core”
bindings like C-n.  Though I personally haven’t really found that to be
problematic, as I prefer p and n over C-p and C-n anyway.  You can have
a look at my config here [1] or the example config there [2], to get an
idea of what’s possible.

[0]: https://github.com/tridactyl/tridactyl
[1]: https://git.sr.ht/~bandali/dotfiles/tree/master/.config/tridactyl/tridactylrc
[2]: https://github.com/tridactyl/tridactyl/blob/master/.tridactylrc

Specifically, for editing textareas in Emacs, it’ll pick up your $EDITOR
or you can set the editor explicitly using its editorcmd option [3].

[3]: https://git.sr.ht/~bandali/dotfiles/commit/2446aab5a76e00157c62e13ec06b09370df3519a

Hope this helps.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Amin Bandali <bandali@gnu.org>
> Date: Sat, 11 May 2019 09:29:48 -0400
> 
> >> https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/
> >
> > Much better, thanks.
> >
> 
> You could also go for something like Tridactyl [0], which allows you to
> accomplish various tasks using only your keyboard.

This looks like Emacs-like keybindings in a browser?  If so, that
wasn't the point: my problem with a Web browser is not the lack of
keybindings, it's the lack of functionality.  The message to which you
responded described a way to let one edit the text area in Emacs, not
to have Emacs-like keybindings in the browser edit box.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sat, 11 May 2019 16:58:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Amin Bandali <bandali@gnu.org>
> > Date: Sat, 11 May 2019 09:29:48 -0400
> > 
> > >> https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/
> > >
> > > Much better, thanks.
> > >
> > 
> > You could also go for something like Tridactyl [0], which allows you to
> > accomplish various tasks using only your keyboard.
> 
> This looks like Emacs-like keybindings in a browser?

No, it isn't.  I misunderstood, sorry.

However, programming a browser in JS is not something I'd be excited
to do in order to be able to have decent text-editing capabilities.
IMO, that's really gross.

Re: [RFE] Migration to gitlab

[Amin Bandali]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 11 May 2019 16:58:22 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: Amin Bandali <bandali@gnu.org>
>> > Date: Sat, 11 May 2019 09:29:48 -0400
>> > 
>> > >> https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/
>> > >
>> > > Much better, thanks.
>> > >
>> > 
>> > You could also go for something like Tridactyl [0], which allows you to
>> > accomplish various tasks using only your keyboard.
>> 
>> This looks like Emacs-like keybindings in a browser?
>
> No, it isn't.  I misunderstood, sorry.
>

No problems.

>
> However, programming a browser in JS is not something I'd be excited
> to do in order to be able to have decent text-editing capabilities.
> IMO, that's really gross.
>

Of course, I don’t like touching JS with a 10ft pole either.  Luckily
other brave souls have taken it upon themselves to do it by making tools
like Tridactyl and we can enjoy the fruits of their efforts.  For better
or worse, Tridactyl’s config file mostly looks like Vim’s; so you’re not
really writing any JS to change any of its settings (unless you choose
to do so, of course) but rather you’re setting its different options.

Also, a side note: Tridactyl doesn’t do much in the way of improving the
text-editing experience in the browser itself.  Most of its usefulness
actually shines when you’re *not* editing text, by letting you bind your
preferred keys (e.g. p and n) for actions like scrolling up and down or
opening/closing tabs and many other things.  Editing text is actually
where it steps aside and lets you edit textareas in your favourite
editor.  Do I wish I could seamlessly and securely browse through the
“modern web” without leaving Emacs?  Of course.  But in lieu of that, I
find the next best thing for me is to have some resemblance of Emacs
(e.g. its keybindings) in IceCat while browsing, and having an addon
that would let me edit textareas in Emacs.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Amin Bandali <bandali@gnu.org>
> Date: Sat, 11 May 2019 10:42:57 -0400
> 
> Do I wish I could seamlessly and securely browse through the “modern
> web” without leaving Emacs?  Of course.  But in lieu of that, I find
> the next best thing for me is to have some resemblance of Emacs
> (e.g. its keybindings) in IceCat while browsing, and having an addon
> that would let me edit textareas in Emacs.

Browsing the Web is one thing, using a browser to work on code is
something very different.  I've learned Emacs many years ago to be
able to do almost everything in a single integrated environment.  I'd
prefer not to have to to go to another tool for a large and important
part of what I need to do here.

Re: [RFE] Migration to gitlab

[Amin Bandali]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Amin Bandali <bandali@gnu.org>
>> Date: Sat, 11 May 2019 10:42:57 -0400
>> 
>> Do I wish I could seamlessly and securely browse through the “modern
>> web” without leaving Emacs?  Of course.  But in lieu of that, I find
>> the next best thing for me is to have some resemblance of Emacs
>> (e.g. its keybindings) in IceCat while browsing, and having an addon
>> that would let me edit textareas in Emacs.
>
> Browsing the Web is one thing, using a browser to work on code is
> something very different.  I've learned Emacs many years ago to be
> able to do almost everything in a single integrated environment.  I'd
> prefer not to have to to go to another tool for a large and important
> part of what I need to do here.
>

Oh sure, I think we’re in complete agreement there :)

And to say something about the main topic of the thread (discussion
about use of GitLab for Emacs development), as myself and a few others
previously mentioned, Sourcehut [0] is a serious contender that could be
more readily suitable for Emacs development than GitLab, because of its
email-centric workflows and the optional and minimal web interface for
those that want it (rather than trying to shoehorn email integration on
top of a heavy web app as an afterthought, as in the case of GitLab).
But I shall not derail the focus of this thread’s discussion about
GitLab and its merits and features, and the desired features it still
lacks; especially since Sourcehut still has to mature a bit more to be a
considered as a replacement for all of Savannah or GitLab as proposed.
Regardless, I think Sourcehut is a promising forge to keep an eye on,
with workflows compatible with our existing ones.  I’ll likely bring it
up later when this discussion about GitLab gets somewhere (e.g. when we
get to a prioritized list of features desired by the “main” Emacs devs,
as well as by new/potential contributors).

[0]: https://sourcehut.org

Re: [RFE] Migration to gitlab

[Amin Bandali]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Amin Bandali <bandali@gnu.org>
>> Date: Sat, 11 May 2019 09:29:48 -0400
>> 
>> >> https://addons.mozilla.org/en-US/firefox/addon/edit-with-emacs1/
>> >
>> > Much better, thanks.
>> >
>> 
>> You could also go for something like Tridactyl [0], which allows you to
>> accomplish various tasks using only your keyboard.
>
> This looks like Emacs-like keybindings in a browser?  If so, that
> wasn't the point: my problem with a Web browser is not the lack of
> keybindings, it's the lack of functionality.  The message to which you
> responded described a way to let one edit the text area in Emacs, not
> to have Emacs-like keybindings in the browser edit box.
>

I understood that.  My message was about both: in the first paragraph I
mentioned how one could use Tridactyl and get Emacs-like keybindings in
Firefox/IceCat’s; and in the second paragraph I mentioned that like the
addon suggested by Dmitry, Tridactyl too allows one to edit textareas in
Emacs.  So it covers both use-cases, for people that like to use Emacs
to edit textareas but also get Emacs-like bindings in the browser.

Re: [RFE] Migration to gitlab

[조성빈]

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

There’s also this: https://github.com/GhostText/GhostText
From my friends feedback, it is more maintained and less buggy; YMMV. (I’ve never tried this one)

2019. 5. 11. 오후 3:13, Eli Zaretskii <eliz@gnu.org> 작성:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Fri, 10 May 2019 23:12:08 +0200
>> 
>> It is possible to use Emacs to write text areas on web pages with an
>> extension. You enter the text area and with a key combination (1)
>> emacsclient is invoked. Those of us that are mouse-averse can use
>> extensions that make possible to click links, buttons, etc using the
>> keyboard, it is much more efficient than the mouse. There are more
>> possibilities to make the web less painful, it is just a matter of
>> installing two or three extensions and that takes no time if someone (2)
>> points you to the right place.
> 
> With which browsers is this possible?  Any further details about such
> extensions?
> 
> Thanks.
> 

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

Re: [RFE] Migration to gitlab

[Toon Claes]

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

조성빈 <pcr910303@icloud.com> writes:

> There’s also this: https://github.com/GhostText/GhostText
> From my friends feedback, it is more maintained and less buggy; YMMV. (I’ve never tried this one)

This one works also with Firefox btw.


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> Instead, GitLab wants me to use the Web browser for most of these.
> This means the Web browser now becomes a very important program for
> me, I need to start learning it much more than I bothered until now, I
> need to keep it updated at all times, I need to customize it (more
> things to learn and try), etc.

It's even much worse: web browsers can't be customized, by and large,
and their behavior depends more on the web-site you're visiting than on
your customizations.  So, you're basically stuck with whatever the
website author chooses.

> I wonder if I'm the only one here who feels that way.

Definitely not.  The web-browser has its up-sides, but working within it
is a royal PITA.


        Stefan

Re: [RFE] Migration to gitlab

[Alex Gramiak]

Eli Zaretskii <eliz@gnu.org> writes:

> I wonder if I'm the only one here who feels that way.  I mean, one of
> the more important advantages of Emacs is that it lets you do many
> things only tangentially related to editing program sources, and now
> we suddenly are willing to give that up?  Really??

I imagine that most of the people advocating for a switch to platforms
like Gitlab don't want to give that up; instead, the browser would just
be an alternative for people who don't (perhaps yet) want to (or know
how to) do it in Emacs all the time. I'm one of the people that would
like Emacs development to switch to Gitlab (or suitable equivalent), but
would still plan to do most contributions through Emacs for the reasons
you described.

A problem here seems to be that Gitlab, outside of its browser workflow,
doesn't currently offer some niceties that are to be expected, but
hopefully this discussion helps to nudge the right people to work on
these features there.

If switching to Gitlab was given the OK by you and other core
contributors after the desired features are available in Gitlab, then
work on an Emacs frontend for Gitlab (that can be put in ELPA) would be
much more enticing.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  toon@iotcl.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 10 May 2019 15:56:25 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I wonder if I'm the only one here who feels that way.  I mean, one of
> > the more important advantages of Emacs is that it lets you do many
> > things only tangentially related to editing program sources, and now
> > we suddenly are willing to give that up?  Really??
> 
> I imagine that most of the people advocating for a switch to platforms
> like Gitlab don't want to give that up; instead, the browser would just
> be an alternative for people who don't (perhaps yet) want to (or know
> how to) do it in Emacs all the time.

I believe you are talking about a system with dual interface: one via
a browser, and another that allows to use Emacs for most of the tasks.

That'd be OK at least with me, but the problem is I don't yet see how
this could be done with GitLab or any other system that was mentioned
in the discussions so far.

> A problem here seems to be that Gitlab, outside of its browser workflow,
> doesn't currently offer some niceties that are to be expected, but
> hopefully this discussion helps to nudge the right people to work on
> these features there.

I really hope so.

> If switching to Gitlab was given the OK by you and other core
> contributors after the desired features are available in Gitlab

For this, we'd need to agree on the list of the desired features,
probably prioritized by their importance.  Once we have that, we could
decide that having all the features whose priority is greater than
some agreed-upon number N is enough to switch.  Theoretically, I don't
see any problems with this decision; the devil is as always in the
details: to come up with a list of the features, agree on their
priorities, and implement them.

Thanks.

Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  agrambot@gmail.com
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 10 May 2019 19:33:56 +0300
>> 
>> On 10.05.2019 17:19, Eli Zaretskii wrote:
>> 
>> > Yes, my point was that having to work via a Web browser will need to
>> > switch frequently between it and Emacs.  Which is an annoyance, to say
>> > the least.
>> 
>> I can believe that, even if I don't really understand it.
>
> Let me try to explain.
>
> In any editing environment that is not Emacs I lack many features that
> make my work significantly more efficient.  I miss the almost instant
> completion with M-/ (since I have the Emacs manuals and the TAGS
> tables loaded into Emacs at all times, all the symbols are instantly
> found, and I seldom if ever need to type long names like
> mark_window_display_accurate_1).  I miss my abbrevs (which also allow
> me to fix some of my more frequent typos, or type stuff like "naïve" o
> "façade" without switching keyboard).  I miss the convenience of being
> able to jump to any function/macro/typedef with just "C-u M-."  (or
> even just M-. if I'm in a code buffer).  I miss the multi-buffer
> search capabilities and Grep.  I miss a more-or-less immediate access
> to the Git repository.  I miss the capability to apply a patch which
> I'm looking at, and be able to compile the result right after that,
> right from the editor.
>
> And these are just the tools I use almost all the time.
>
> Instead, GitLab wants me to use the Web browser for most of these.
> This means the Web browser now becomes a very important program for
> me, I need to start learning it much more than I bothered until now, I
> need to keep it updated at all times, I need to customize it (more
> things to learn and try), etc.  And after all that I still get an
> abysmally inadequate text editing widget, lacking most if not all of
> the features I mentioned above, while for tasks other than
> writing/editing text you ask me to switch between the browser and
> Emacs.  That's a massive degradation of my quality of life.
>
> I wonder if I'm the only one here who feels that way.  I mean, one of
> the more important advantages of Emacs is that it lets you do many
> things only tangentially related to editing program sources, and now
> we suddenly are willing to give that up?  Really??
>
>> Anyway, IIRC your current stance on that issue is that we'll need an 
>> Emacs-based client anyway, even just for the issues tracker.
>
> I don't have a "stance".  My personal preference is to do as much as
> possible from within Emacs, certainly any significant text/source code
> editing related to Emacs maintenance.  I would be very unhappy if
> forced instead to use a text-editing widget of a browser, and its
> rudimentary email capabilities.
>
> Two possible ways of working with an issue tracker that don't require
> me to switch from Emacs are: (1) email and (2) an Emacs front-end.
> Either one, or even a combination of them, will, for me, be much
> better than a pure Web UI.
>
> I'm very interested in hearing opinions of other core maintainers and
> developers.

FWIW, though I'm relatively comfortable with GitLab/GitHub UIs and
workflows and understand why they are more popular with and seem more
familiar and intuitive to new contributors, I too would be sad to see
Emacs move away from a text- and email- to a web-based UI.  Working
within Emacs simply offers too many conveniences, as you have already
described, to gladly give up.

Re: configuring or improving GitLab's support for an email workflow vs
having an Emacs client - I think the former is always a nice-to-have,
but I'm not sure to what extent it can be achieved in a practical sense,
so the latter is probably a must-have.

One example that comes to mind is inline edits.  Debbugs data is pretty
static - once an email has been sent, it can't be edited.  GitLab
comments, OTOH, can be edited, deleted, reacted to with "thumbs up" and
"thumbs down", etc.  Sure, notification of these events by email can be
tweaked so that other participants are made aware, but I bet there will
always be either a loss or deluge of certain information - the web UI
just seems inherently more dynamic than email.  So a debbugs-like
client, which fetches the latest state of an issue or merge request
being visited each time, seems more realistic/applicable to me.

Thanks,

-- 
Basil

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 10.05.2019 23:43, Eli Zaretskii wrote:

>>> Yes, my point was that having to work via a Web browser will need to
>>> switch frequently between it and Emacs.  Which is an annoyance, to say
>>> the least.
>>
>> I can believe that, even if I don't really understand it.
> 
> Let me try to explain.

Before I reply to the rest, I'd like to clarify: my surprise was at the 
declared difficulty of switching between the web browser and Emacs. 
Which, by itself, is a few keypresses.

Working with the debbugs package inside Emacs also requires some 
keypresses, some context switching, and it changes the window 
configuration in the current Emacs session, which is also a cost.

> In any editing environment that is not Emacs I lack many features that
> make my work significantly more efficient.  I miss the almost instant
> completion with M-/ (since I have the Emacs manuals and the TAGS
> tables loaded into Emacs at all times, all the symbols are instantly
> found, and I seldom if ever need to type long names like
> mark_window_display_accurate_1).  I miss my abbrevs (which also allow
> me to fix some of my more frequent typos, or type stuff like "naïve" o
> "façade" without switching keyboard).  I miss the convenience of being
> able to jump to any function/macro/typedef with just "C-u M-."  (or
> even just M-. if I'm in a code buffer).  I miss the multi-buffer
> search capabilities and Grep.  I miss a more-or-less immediate access
> to the Git repository.  I miss the capability to apply a patch which
> I'm looking at, and be able to compile the result right after that,
> right from the editor.

Out of these, I still use Emacs for more or less everything but abbrevs 
and word completion. IOW, for everything except writing prose, and I 
still might copy-paste some snippets of code or text between it and the 
web browser or the email client.

Writing text in something other than Emacs is not particularly 
enjoyable, but turns out, certain kinds of text are 
fetched/rendered/displayed better in other tools. And you generally have 
to edit the said kinds of text in the same tools that you're reading 
them in. In particular, after a few years of trying Gnus for email, I 
went back to Thunderbird, losing with that all the benefits of 
everything-inside-Emacs email workflow. So the use of web browser 
doesn't make it worse (and makes certain other things better).

> Instead, GitLab wants me to use the Web browser for most of these.

As per above, I disagree.

> This means the Web browser now becomes a very important program for
> me, I need to start learning it much more than I bothered until now, I
> need to keep it updated at all times, I need to customize it (more
> things to learn and try), etc.

That is true, of course. Alas, the contemporary Internet makes browsers 
quite indispensable.

>> Anyway, IIRC your current stance on that issue is that we'll need an
>> Emacs-based client anyway, even just for the issues tracker.
> 
> I don't have a "stance".  My personal preference is to do as much as
> possible from within Emacs, certainly any significant text/source code
> editing related to Emacs maintenance.  I would be very unhappy if
> forced instead to use a text-editing widget of a browser, and its
> rudimentary email capabilities.

Speaking of email capabilities, GitLab does offer some improvements, 
such as reliable subscription to discussions, as well as being able to 
unsubscribe. And, when used correctly, no duplicate emails are going to 
arrive. The "from" email address in its messages might look weird, but 
it serves a purpose.

> Two possible ways of working with an issue tracker that don't require
> me to switch from Emacs are: (1) email and (2) an Emacs front-end.
> Either one, or even a combination of them, will, for me, be much
> better than a pure Web UI.

To be fair, the GitLab documentation, as well as Salsa FAQ (see my 
another message), give the impression that most operations *are* 
possible to do via email.

>> Click on one of them and choose the last item: Custom. You will then be
>> able to choose the events to get notifications for.
>>
>> MR reassignments are in that list.
> 
> I cannot see it, because I cannot log in.  Are there only 2
> possibilities: all or nothing?  I do want to see reassignments to
> myself.

I'm not sure, but your question is very reasonable. Maybe it already 
works like we'd expect (e.g. the configuration affects all issues in 
general, but the issues where you're subscribed directly, either 
manually or by a mention, will send all notifications).

We could ask someone or just try it out.

>> Here's also the same information on the API level:
>> https://docs.gitlab.com/ee/api/notification_settings.html
> 
> Where is each value described?  The names are not descriptive enough,
> and I couldn't find any details about them.  Did I miss something?

You can search the documentation or ask. I think (as a person familiar 
with GitLab) that all names are quite descriptive.

The configuration page inside your GitLab profile (one I've linked to) 
has slightly different, maybe easier to understand descriptions.

>> Not sure if that list is exhaustive, or if there are emails we'd want to
>> configure off but cannot. That would, again, be something to ask the
>> GitLab developers for.
> 
> If there's no more detailed documentation, I think we should ask them
> now what does exist and what is possible to have given some small
> effort.

Maybe Toon could ask, or answer the question himself.

>>> Email filters are the last resort in my book.  It would also be in
>>> yours, if you considered a possibility to work via email.
>>
>> But I already do, here.
> 
> I never needed to set up any filters.  Never.  It sounds very wrong to
> me that I need to set up a filter to defend myself against my own
> project.

Well, I routinely get duplicate emails because I'm both subscribed to 
emacs-devel and the bug tracker, and also get Cc'd. I ignore that, but 
some people suggested technical solutions.

>> No, I'm suggesting to use it as a sandbox at first. Post some random
>> issues, close them, reopen them, write some comments, receive comments
>> from others, respond to them over email, etc, and see how well that
>> works, and what the main problems are.
>>
>> To post a new issue, you can navigate to
>> https://emba.gnu.org/emacs/emacs/issues and click "New issue". This also
>> requires registration (at least, for now (**)).
> 
> I will try to find time for this, but it won't happen soon: there are
> several urgent tasks on my plate.  Perhaps someone else could do that
> and post the experiences.

Everybody is welcome to try and report. I've opened one issue, but I 
can't really test everything by myself.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 13.05.2019 4:43, Dmitry Gutov wrote:
> The "from" email address in its messages might look weird, but it serves 
> a purpose.

Sorry, I meant the "reply to" address. The "from" is generally fine.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  agrambot@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 13 May 2019 04:43:00 +0300
> 
> On 10.05.2019 23:43, Eli Zaretskii wrote:
> 
> >>> Yes, my point was that having to work via a Web browser will need to
> >>> switch frequently between it and Emacs.  Which is an annoyance, to say
> >>> the least.
> >>
> >> I can believe that, even if I don't really understand it.
> > 
> > Let me try to explain.
> 
> Before I reply to the rest, I'd like to clarify: my surprise was at the 
> declared difficulty of switching between the web browser and Emacs. 

Not "difficulty", "annoyance".  Quite a different thing, I'd say.  You
want me to copy/paste the text to Emacs, edit there, then copy/paste
back?  The switch itself is the least of the problems.

> Out of these, I still use Emacs for more or less everything but abbrevs 
> and word completion. IOW, for everything except writing prose, and I 
> still might copy-paste some snippets of code or text between it and the 
> web browser or the email client.
> 
> Writing text in something other than Emacs is not particularly 
> enjoyable, but turns out, certain kinds of text are 
> fetched/rendered/displayed better in other tools. And you generally have 
> to edit the said kinds of text in the same tools that you're reading 
> them in. In particular, after a few years of trying Gnus for email, I 
> went back to Thunderbird, losing with that all the benefits of 
> everything-inside-Emacs email workflow. So the use of web browser 
> doesn't make it worse (and makes certain other things better).

That's you, not me.  (And I don't use Gnus, either; Emacs has more
than a single email client to offer.)

> > Instead, GitLab wants me to use the Web browser for most of these.
> 
> As per above, I disagree.

So for you the Emacs solution will not be needed.  But there are
enough of those who'd want it.

> > This means the Web browser now becomes a very important program for
> > me, I need to start learning it much more than I bothered until now, I
> > need to keep it updated at all times, I need to customize it (more
> > things to learn and try), etc.
> 
> That is true, of course. Alas, the contemporary Internet makes browsers 
> quite indispensable.

Not in my workflows.  I use it quite rarely, and generally not for
working on code (except when I need to consult documentation, or find
a solution to some problem I bump into).

> >> Here's also the same information on the API level:
> >> https://docs.gitlab.com/ee/api/notification_settings.html
> > 
> > Where is each value described?  The names are not descriptive enough,
> > and I couldn't find any details about them.  Did I miss something?
> 
> You can search the documentation

Granted, I already did.  And came up empty-handed.

> or ask. I think (as a person familiar with GitLab) that all names
> are quite descriptive.

Well, perhaps then you could explain these to me:

 . the "mention" level
 . the "global" level
 . from the "custom" level:
   - issue_due
   - push_to_merge_request and merge_merge_request

> > I never needed to set up any filters.  Never.  It sounds very wrong to
> > me that I need to set up a filter to defend myself against my own
> > project.
> 
> Well, I routinely get duplicate emails because I'm both subscribed to 
> emacs-devel and the bug tracker, and also get Cc'd. I ignore that, but 
> some people suggested technical solutions.

This is standard in almost all mailing lists, and easy to ignore.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 13.05.2019 17:48, Eli Zaretskii wrote:

>> Before I reply to the rest, I'd like to clarify: my surprise was at the
>> declared difficulty of switching between the web browser and Emacs.
> 
> You
> want me to copy/paste the text to Emacs, edit there, then copy/paste
> back?

No, I just meant Alt-Tab.

But to answer your question: maybe, sometimes. Though if you mean to 
copy-paste to Emacs the previous message, split it into quotes, write a 
reply and copy-paste it back, then no, it's not something I ever do or 
recommend. I only ever copy-paste in one direction (identifiers or code 
snippets, mostly). Of course, the browser extensions we've mentioned 
("Edit in Emacs") might create some different tradeoffs.

> So for you the Emacs solution will not be needed.  But there are
> enough of those who'd want it.

The option to reply via email is still available. So I imagine you could 
only go for the browser version for the more complex actions, but not 
when writing a simple reply.

>> or ask. I think (as a person familiar with GitLab) that all names
>> are quite descriptive.
> 
> Well, perhaps then you could explain these to me:
> 
>   . the "mention" level

Suppose your login is going to be 'eliz'. Then if somebody writes 
'@eliz' in a comment to a bug report, that's called a "mention".

The description of that level on the notification settings page says:

    You will receive notifications only for comments
    in which you were @mentioned

>   . the "global" level

It means to use the "global" notification settings for this particular 
project. They are configured separately, and have the save options.

>   . from the "custom" level:
>     - issue_due

Apparently a notification for an issue that had missed its due date: 
https://about.gitlab.com/2016/04/22/gitlab-8-7-released/

Never used that feature, personally.

>     - push_to_merge_request

Whenever there is a push to the branch associated with an open merge 
request.

Normally happens when the patch submitter addresses the review comments 
and pushes the corresponding changes.

 >  and merge_merge_request

When a merge request is merged.

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hmm. Let's see if it can be configured as well, or we can add that to
> the list of requirements on the GitLab-CE issue Toon opened.

From Emacs requirements issue, I've linked to "Increase granularity of
email notification settings":
https://gitlab.com/gitlab-org/gitlab-ce/issues/29884

I think there a lot of different types of email notifications and for
those also several conditions (e.g. like a "only email me when
reassigned to me" setting). So it would require a fair amount of
research to compose a complete list of settings. 

> No, I'm suggesting to use it as a sandbox at first. Post some random
> issues, close them, reopen them, write some comments, receive comments
> from others, respond to them over email, etc, and see how well that
> works, and what the main problems are.

Yes, I would also want to set up a sandbox. We can create a new dummy
project on EMBA for this. If we can extract the bugs from debbugs to a
CSV format, we even should be able to import them to GitLab. That also
might help us to test the limitations of Forge.

> (*) I think currently registration is only manual, so we'll need to
> ask Toon to create an account.

There are a number of email domains whitelisted, like: @gnu.org,
@fsf.org. Users with an email address on those domains can register
without restriction. Or I can create the account for you. And there are
several other admins who can do that: Nicolas Petton, Michael Albinus,
Ted Zlatanov, and recently also you Dmitry.

Just to make clear, it's not my objective to run EMBA on my own. I'm
here to help, but I don't want to limit anyone in their
possibilities. So if anyone wants access to anything, please let us
know.


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 13.05.2019 12:03, Toon Claes wrote:

>  From Emacs requirements issue, I've linked to "Increase granularity of
> email notification settings":
> https://gitlab.com/gitlab-org/gitlab-ce/issues/29884
> 
> I think there a lot of different types of email notifications and for
> those also several conditions (e.g. like a "only email me when
> reassigned to me" setting). So it would require a fair amount of
> research to compose a complete list of settings.

I really wonder what happens if I have set e.g. a "Mention" notificaion 
level for the Emacs project, and then I open an issue, or subscribe to 
an existing one. Would GitLab still only send notifications for @mentions?

> Yes, I would also want to set up a sandbox. We can create a new dummy
> project on EMBA for this.

I just created a "test" issue on the main Emacs project, but sure, it 
could be more proper to create a separate project as a test bed.

 > If we can extract the bugs from debbugs to a
 > CSV format, we even should be able to import them to GitLab. That also
 > might help us to test the limitations of Forge.

It's a question of "when" and "who", but not "if", I think. :-)

> And there are
> several other admins who can do that: Nicolas Petton, Michael Albinus,
> Ted Zlatanov, and recently also you Dmitry.
Ah, that is right. I see the admin area now.

BTW, looks like the "Reply by email" feature is not configured yet.

EMBA enable Reply by Email (was: [RFE] Migration to gitlab)

[Toon Claes]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> BTW, looks like the "Reply by email" feature is not configured yet.

Ah, good point. We'd have to modify our Ansible playbooks for that, and
maybe need some assistance from FSF sysadmins:
https://gitlab.com/emacs-ci/emba-ansible/issues/9


-- 
Toon

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

Re: [RFE] Migration to gitlab

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> On debbugs, I also always forget how to use the control server
>> >> commands.
>> > 
>> > Having a need to use the control command is rare, so I don't think
>> > this is a serious disadvantage.
>> 
>> Rare to set the "found in" or "fixed in" versions? Or retitle a bug? Or 
>> reopen? Or assign it to somebody?
>
> Yes, all of the above.  Just look at how much these are used in Emacs.

I recently tried to change the title of a bug report. After searching
the instructions on the web, reading them and sending the e-mail with
the command, it had no effect, so I did something wrong. But I don't
care. I'll never waste another 10 minutes of my time on such endeavours
again.

Yesterday I had to change the title of a bug on github for the first
time. It took a few seconds and worked right away.

For one-off or occasional contributors, debbugs is a pig.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 10 May 2019 16:02:44 +0200
> 
> I recently tried to change the title of a bug report. After searching
> the instructions on the web, reading them and sending the e-mail with
> the command, it had no effect, so I did something wrong. But I don't
> care. I'll never waste another 10 minutes of my time on such endeavours
> again.
> 
> Yesterday I had to change the title of a bug on github for the first
> time. It took a few seconds and worked right away.
> 
> For one-off or occasional contributors, debbugs is a pig.

There's no reason for one-off contributors to retitle a bug report.

Re: [RFE] Migration to gitlab

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Fri, 10 May 2019 16:02:44 +0200
>> 
>> I recently tried to change the title of a bug report. After searching
>> the instructions on the web, reading them and sending the e-mail with
>> the command, it had no effect, so I did something wrong. But I don't
>> care. I'll never waste another 10 minutes of my time on such endeavours
>> again.
>> 
>> Yesterday I had to change the title of a bug on github for the first
>> time. It took a few seconds and worked right away.
>> 
>> For one-off or occasional contributors, debbugs is a pig.
>
> There's no reason for one-off contributors to retitle a bug report.

About the same reasons as for anybody else.

Anyways, my gripes about debbugs are not limited to the command system.
Maybe 30 years ago it looked like an improvement, but for the last 20
years it can hardly qualify as a pile of hacks shoehorning a primitive
issue tracker on top of a mailing list.

The fact that you can't even subscribe to a bug# is appalling.

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 10 May 2019 16:54:43 +0200
> 
> >> For one-off or occasional contributors, debbugs is a pig.
> >
> > There's no reason for one-off contributors to retitle a bug report.
> 
> About the same reasons as for anybody else.

Exactly.  IOW: none at all.

> Anyways, my gripes about debbugs are not limited to the command system.
> Maybe 30 years ago it looked like an improvement, but for the last 20
> years it can hardly qualify as a pile of hacks shoehorning a primitive
> issue tracker on top of a mailing list.
> 
> The fact that you can't even subscribe to a bug# is appalling.

We should invest more energy in finding better systems and adapting
them to our needs, and less in arguing how bad debbugs is.  That's why
I posted my comments on GitLab.  I hope someone will find ways of
overcoming those issues, or maybe will find a system that has fewer
issues and is better suited to how we work and want to work.

Re: [RFE] Migration to gitlab

[Alan Mackenzie]

Hello, Óscar.

On Fri, May 10, 2019 at 16:54:43 +0200, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Fri, 10 May 2019 16:02:44 +0200

> >> I recently tried to change the title of a bug report. After searching
> >> the instructions on the web, reading them and sending the e-mail with
> >> the command, it had no effect, so I did something wrong. But I don't
> >> care. I'll never waste another 10 minutes of my time on such endeavours
> >> again.

> >> Yesterday I had to change the title of a bug on github for the first
> >> time. It took a few seconds and worked right away.

> >> For one-off or occasional contributors, debbugs is a pig.

> > There's no reason for one-off contributors to retitle a bug report.

> About the same reasons as for anybody else.

> Anyways, my gripes about debbugs are not limited to the command system.
> Maybe 30 years ago it looked like an improvement, but for the last 20
> years it can hardly qualify as a pile of hacks shoehorning a primitive
> issue tracker on top of a mailing list.

Actually, I quite like debbugs.  It is a bug system which doesn't force
one to use a web browser for its normal operation, and allows this
normal operation with a minimum of shackles and rules.  For me, it means
I'm not continually forced to switch back and forth between text work
and the GUI.  I prefer debbugs to bugzilla, for example.

> The fact that you can't even subscribe to a bug# is appalling.

No.  It's just an unforeseen feature which hasn't yet been implemented.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [RFE] Migration to gitlab

[Juri Linkov]

> I recently tried to change the title of a bug report. After searching
> the instructions on the web, reading them and sending the e-mail with
> the command, it had no effect, so I did something wrong. But I don't
> care. I'll never waste another 10 minutes of my time on such endeavours
> again.

Shouldn't debbugs retitle the bug itself when you edit the subject
and send the e-mail to the same bug but with a new subject?

So efforts could be directied into improving debbugs package and website,
until GitLab provides a decent API and Emacs frontend is implemented for it,
or at least until GitLab provides JavaScript-free Web UI accessible by eww.

Re: [RFE] Migration to gitlab

[Óscar Fuentes]

Juri Linkov <juri@linkov.net> writes:

>> I recently tried to change the title of a bug report. After searching
>> the instructions on the web, reading them and sending the e-mail with
>> the command, it had no effect, so I did something wrong. But I don't
>> care. I'll never waste another 10 minutes of my time on such endeavours
>> again.
>
> Shouldn't debbugs retitle the bug itself when you edit the subject
> and send the e-mail to the same bug but with a new subject?

MUAs add all sorts of garbage to subjects without the user's
intervention.

Re: [RFE] Migration to gitlab

[Stefan Monnier]

>>> I recently tried to change the title of a bug report. After searching
>>> the instructions on the web, reading them and sending the e-mail with
>>> the command, it had no effect, so I did something wrong. But I don't
>>> care. I'll never waste another 10 minutes of my time on such endeavours
>>> again.
>>
>> Shouldn't debbugs retitle the bug itself when you edit the subject
>> and send the e-mail to the same bug but with a new subject?
>
> MUAs add all sorts of garbage to subjects without the user's
> intervention.

Plus sometimes people send a new message to a bug without replying
(i.e. by crating the message from scratch), in which case they rarely
copy the exact same subject, yet they don't intend to change the
bug's subject.


        Stefan

Debbugs problems (was: [RFE] Migration to gitlab)

[Stefan Monnier]

>> I understand. That's why I want to figure out whether we can add changes
>> to GitLab, so (almost) everything also can be done outside the
>> webbrowser, and from emacs. Or maybe build something like the debbugs
>> package for emacs.
> Personally, I think an Emacs client is almost a must, if we want to
> consider something like GitLab seriously.

I largely agree, tho if the interaction can all be done via git+email,
I'd be quite satisfied as well.

>> Probably the most complicated about the current bug tracker, at least
>> from irregular contributor's POV, is interacting to a existing bug:
>> Where do I send the email to? Who do I CC? How do I set In-Reply-To?
> In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
> the defaults always DTRT.  You don't need to think about any of that.

I think this is not nearly as obvious: most users I know consider "reply
only to sender" as the normal way to reply (and look at "reply all" with
fear, because they never use mailing-lists).  Furthermore, while maybe
all it takes is "to reply", they likely don't know that and will end up
having to think about it.

Another problem of debbugs in my experience is that there's no way to
"subscribe" to a bug.


        Stefan

Re: Debbugs problems

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Another problem of debbugs in my experience is that there's no way to
> "subscribe" to a bug.

This is bug#5439. I haven't checked recently about the state of affairs
in the Debian project, but I hope this has been improved there. We would
profit from this when we'll merge our debbugs fork with the original
software; a project on the way with slow progress.

Since this is the most demanding request for debbugs, we should
implement this on our own, if it doesn't work yet in the Debian debbugs
version.

>         Stefan

Best regards, Michael.

Re: Debbugs problems

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Fri, 10 May 2019 16:24:14 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
> 	Toon Claes <toon@iotcl.com>, agrambot@gmail.com, dgutov@yandex.ru
> 
> Since this is the most demanding request for debbugs, we should
> implement this on our own, if it doesn't work yet in the Debian debbugs
> version.

I agree.  let's do that sooner rather than later.

Thanks.

Re: Debbugs problems

[Dmitry Gutov]

On 10.05.2019 17:24, Michael Albinus wrote:
> This is bug#5439. I haven't checked recently about the state of affairs
> in the Debian project, but I hope this has been improved there. We would
> profit from this when we'll merge our debbugs fork with the original
> software; a project on the way with slow progress.

Speaking of Debian and its affairs, I can see they have introduced their 
own branded version of GitLab: https://wiki.debian.org/Salsa

I'm not sure about how widely it is utilized, but here's some 
documentation that might give insight into Debian's workflows when using 
it: https://wiki.debian.org/Salsa/FAQ and https://wiki.debian.org/Salsa/Doc.

Re: Debbugs problems

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 13 May 2019 04:09:31 +0300
> Cc: Eli Zaretskii <eliz@gnu.org>, Toon Claes <toon@iotcl.com>,
> 	agrambot@gmail.com, emacs-devel@gnu.org
> 
> On 10.05.2019 17:24, Michael Albinus wrote:
> > This is bug#5439. I haven't checked recently about the state of affairs
> > in the Debian project, but I hope this has been improved there. We would
> > profit from this when we'll merge our debbugs fork with the original
> > software; a project on the way with slow progress.
> 
> Speaking of Debian and its affairs, I can see they have introduced their 
> own branded version of GitLab: https://wiki.debian.org/Salsa

That's good to know, but at this point I don't think it matters to us
that there's a Debian variety of GitLab.  Am I mistaken?

Re: Debbugs problems

[Dmitry Gutov]

On 13.05.2019 17:27, Eli Zaretskii wrote:

>> Speaking of Debian and its affairs, I can see they have introduced their
>> own branded version of GitLab: https://wiki.debian.org/Salsa
> 
> That's good to know, but at this point I don't think it matters to us
> that there's a Debian variety of GitLab.  Am I mistaken?

Considering Debian is historically heavy on email-based workflows, and 
it's where we got our original bug tracker from, it might be helpful to 
study how they came to this decision, and how they are coping with the 
transition.

Re: Debbugs problems

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 13 May 2019 20:56:41 +0300
> Cc: toon@iotcl.com, michael.albinus@gmx.de, monnier@IRO.UMontreal.CA,
> 	agrambot@gmail.com, emacs-devel@gnu.org
> 
> Considering Debian is historically heavy on email-based workflows, and 
> it's where we got our original bug tracker from, it might be helpful to 
> study how they came to this decision, and how they are coping with the 
> transition.

Do you know where one could learn about that?  Some public discussions
or Web pages where this was discussed/documented?

Re: Debbugs problems

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Considering Debian is historically heavy on email-based workflows, and 
>> it's where we got our original bug tracker from, it might be helpful to 
>> study how they came to this decision, and how they are coping with the 
>> transition.
>
> Do you know where one could learn about that?  Some public discussions
> or Web pages where this was discussed/documented?

This is interesting, specially points 1.2 and 1.3:

https://wiki.debian.org/Salsa/FAQ

Re: Debbugs problems

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 13 May 2019 20:57:33 +0200
> 
> This is interesting, specially points 1.2 and 1.3:
> 
> https://wiki.debian.org/Salsa/FAQ

Thanks, it was useful reading.

Re: Debbugs problems

[Dmitry Gutov]

On 13.05.2019 21:03, Eli Zaretskii wrote:

>> Considering Debian is historically heavy on email-based workflows, and
>> it's where we got our original bug tracker from, it might be helpful to
>> study how they came to this decision, and how they are coping with the
>> transition.
> 
> Do you know where one could learn about that?  Some public discussions
> or Web pages where this was discussed/documented?

I only know of this announcement: 
https://lists.debian.org/debian-devel-announce/2019/04/msg00010.html

which mentions a discussion that started here: 
https://lists.debian.org/20190320092222.sap73d6ct54gasnp@an3as.eu

I haven't read most of it, but there is this message: 
https://lists.debian.org/debian-vote/2019/03/msg00101.html

which links to a blog post: 
https://jonathancarter.org/2019/03/20/gitlab-and-debian/

Not sure how helpful you are going to find it, though.

Re: Debbugs problems

[Eli Zaretskii]

> Cc: toon@iotcl.com, michael.albinus@gmx.de, monnier@IRO.UMontreal.CA,
>  agrambot@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 13 May 2019 23:20:05 +0300
> 
> > Do you know where one could learn about that?  Some public discussions
> > or Web pages where this was discussed/documented?
> 
> I only know of this announcement: 
> https://lists.debian.org/debian-devel-announce/2019/04/msg00010.html
> 
> which mentions a discussion that started here: 
> https://lists.debian.org/20190320092222.sap73d6ct54gasnp@an3as.eu
> 
> I haven't read most of it, but there is this message: 
> https://lists.debian.org/debian-vote/2019/03/msg00101.html
> 
> which links to a blog post: 
> https://jonathancarter.org/2019/03/20/gitlab-and-debian/
> 
> Not sure how helpful you are going to find it, though.

Thanks.  Most of the issues aren't applicable to us, but still, it was
educational.

Re: [RFE] Migration to gitlab

[Dmitry Gutov]

On 10.05.2019 12:16, Toon Claes wrote:
> Unfortunately, GitLab does not send out an email
> with patches whenever the author pushes changes to their feature
> branch.

Doesn't it? At least when there is an open MR, the people subscribed to 
it get notifications about any pushes (with links to commits).

Re: [RFE] Migration to gitlab

[Toon Claes]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10.05.2019 12:16, Toon Claes wrote:
>> Unfortunately, GitLab does not send out an email
>> with patches whenever the author pushes changes to their feature
>> branch.
>
> Doesn't it? At least when there is an open MR, the people subscribed
> to it get notifications about any pushes (with links to commits).

The commits, yes. But not the diffs.

-- 
Toon

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

Re: [RFE] Migration to gitlab

[Stefan Monnier]

> This probably still a shortcoming in GitLab. You are right, to get the
> code locally, you need to fetch and checkout the feature branch the
> contributor created.

Ideally for me, the merge-requests should appear as branches within the
*emacs.git* repository (e.g. in refs/merge-requests/<foo>?)  so I can
just always fetch all the merge requests when I `git fetch` and have
them available locally?

[ Note: ideally for me, the above should also hold for the message part
  of the merge requests, and by extension for the issue requests as
  well.  ]

> Yes, I tried to stress the importance of email too. I regret to hear the
> email interface of GitLab didn't work for you. I'll have a look whether
> I can suggest changes to make the "litter" configurable. But besides
> from that, are there any other annoyances you've encountered so far?

The "commit-diffs" I get on my Gitlab projects are acceptable but less
readable than those we get for emacs.git (ideally, they should have the
patch part in 100% standard patch format as an attachment, so a local
email client like Gnus can render them in the way the user likes: it's
OK to also include an HTML version with a Gitlab-chosen rendering of the
patch, tho, so I guess I'm mostly talking about the "text/plain"
side of the multipart/alternative).

> I hate to admit it, if email is the top priority, then maybe
> https://sourcehut.org/ is a better alternative than GitLab.

It sounds promising, indeed.  But when I tried to install it to play
with it on my end, I found that it relies *too much* on email for me to
be able to install it easily (I don't have easy admin access to an SMTP
server).


        Stefan

Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sun, 17 Mar 2019 05:17:50 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> It's a lot of contributors out there; at the same time, I see very
> little patches on emacs-devel list.

Patches should not be sent to emacs-devel at all, they should be sent
to the debbugs tracker.  And I looked at the bug list for the past 2
weeks, and counted around 25 patches there, i.e. an average of 1.5
patch per day -- not a small amount by any measure.

> A lot of open-source projects already migrated to gitlab: all 
> FreeDesktop projects, all Gnome projects; and KDE are likely to migrate 
> soon too².

I can show you several projects that didn't.  Each project decides on
their own, as it should be.

> Gnome reports: "After switching to GitLab, I noticed almost
> immediately an increase in contributions from people I hadn’t met
> before. I think GitLab really lowered the threshold for people
> getting started"³.

I don't know enough about these projects to tell whether their
experience is significant enough for us.  Some metrics are missing:
how many SLOCs are in each project? how many distinct areas of domain
expertise are needed to cover the entire codebase? how many developers
who review patches? which language(s) is each project written in?
etc. etc.

In general, Emacs is unlike any other Free Software project by many of
these metrics, so techniques and procedures that work elsewhere
don't necessarily fit what happens here.  We must assess the
techniques, procedures, and the respective tools in the context of the
problems we need to solve and the resources we have to solve them.
Blindly copying experience by others is not a good idea.

> here's a rarely mentioned point, why in particular mailing-list
> workflow is hard for newcomers: almost every mail client out there
> breaks formatting by default; and configuring that out isn't always
> easy

This is Emacs you are talking about, and Emacs developers you are
addressing.  Most of us use some Emacs-based MUA, where such
atrocities just don't happen.

> 	2. Gitlab makes addressing review comments easier. With mailing lists 
> workflow you either need to α) send a v2 of the patch; which is a 
> little frustrating: you need to find message-id to feed it to 
> git-send-email, and then you need to make sure its title lines up with 
> the rest of the series. Or β) resend whole patch-series; which can be 
> just redundant when all you did was a one-line change, and clutters the 
> mailing list. Also, upon sending v3, v4, etc. you need to save 
> somewhere changes since v1. You can put it in actual commits, but for 
> git-history this information is unnecessary.

You seem to be talking about something that happens in other projects.
There are no requirements in Emacs development to do any of that
stuff: you don't need to give versions to your patches, you don't need
to make sure the titles match, etc.  We don't even require you to use
"git format-patch", although it is certainly appreciated.  You _can_
do all of that if you want, but no one requires you to.  Quite a few
people sent just output of the 'diff' command, and no one rejected
that just because it didn't include all the bells and whistles.

So I see no reason for contributors to do anything beyond starting a
local branch and delivering the patches from there.  I'm sure sending
patches relative to the master branch is very simple, even with Git.
And if even that is too complicated, simply rebase on the latest
master and send the diffs.  How hard can that be?

> With gitlab workflow, on the other hand, you just force-push changes
> to the branch that has merge-request opened. A single command, that
> it.

Likewise to send a patch from a local-branch commit: a single command,
issued from your Emacs MUA via "C-u M-!".

> 	3. CI. I've recently seen someone on emacs-devel⁵ asking a 
> contributor to run their syntax-checking script on a regular basis. 
> That's becase you can't run any check on a code hanging out there on a 
> mailing list in pure air. Gitlab supports CI, i.e. one can set it up to 
> run unit-tests for every merge-request created, so these errors get 
> caught before getting to the tree; and possibly even before getting to 
> eyes of reveiwers.

We already have a server that runs several types of build on each
commit, courtesy of Glenn.  If you stick around long enough, you will
see Glenn blaming commits that broke some build.  This is not exactly
CI, and it runs only on something that lands on master, but it does
mean we are not exactly in the caves here, even without Gitlab...

> 	4. Impossible to lose "merge request". I've seen in Emacs docs an 
> advice to send patch series to a bugtracker, because on emacs-devel 
> they can easily be forgotten. That can't happen so easily with gitlab, 
> where you have a tab with open merge requests.

Can't happen on the tracker, either.  Yes, patches should be sent
there, not here.

> 	5. Discussion on patch series is easier to read. On mailing lists can 
> quickly appear a dozen of no longer relevant review mails, that refer 
> to something that was addressed. In Gitlab the addressed comments can 
> be marked as such, and get collapsed.

I can assure you I am able to filter my email messages as efficiently
as collapsing on Gitlab, if not more so.  I really hope a new system
that we will some day start using will give us more than just an
ability to filter out irrelevant responses.

> 	6. More tightly integrated bugtracker. When a commit refers to an 
> issue, it can be seen from inside the issue. This is useful e.g. when 
> someone fixed a problem, but for some reason couldn't address review 
> comments, leaving the code behind. Then later peoples who stumble upon 
> the same issue can just improve the code instead of doing research and 
> writing it on their own.

You can view each bug/issue via an Emacs package (debbugs, it's on
ELPA), or via a Web browser.  In this way, you also see all the
patches, and can pick up where others left off.

> 	7. Unclear how to download a patch-series from mailing list.

Again, try the debbugs package or point your Web browser to debbugs.
Patches are all there.

That said, I'm not saying we should not consider changing our
processes and tools.  We just need to do that while being aware of the
job(s) to be done by patch reviewers and the resources they have.  For
starters, how many people do you think review patches for Emacs?  It's
good to know the answer before we discuss measures for increasing the
patch flow...

Thanks.