[RFE] Migration to gitlab

classic Classic list List threaded Threaded
280 messages Options
1234 ... 14
Reply | Threaded
Open this post in threaded view
|

[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



Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Konstantin Kharlamov


В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
<[hidden email]> написал:

> 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



Reply | Threaded
Open this post in threaded view
|

Re: [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
<[hidden email]> написал:

>
>
> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> <[hidden email]> написал:
>> 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
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Eli Zaretskii
In reply to this post by Konstantin Kharlamov
> Date: Sun, 17 Mar 2019 05:17:50 +0300
> From: Konstantin Kharlamov <[hidden email]>
> Cc: emacs-devel <[hidden email]>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Tim Cross-5
In reply to this post by Konstantin Kharlamov

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 <[hidden email]> 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
<[hidden email]> написал:
>
>
> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> <[hidden email]> написал:
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Michael Albinus
Tim Cross <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Konstantin Kharlamov
In reply to this post by Tim Cross-5


В Вс, мар 17, 2019 at 11:20 ДП (AM), Tim Cross
<[hidden email]> написал:
>
> 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?".



Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Philippe Vaucher
In reply to this post by Konstantin Kharlamov
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
Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Tadeus Prastowo
On Sun, Mar 17, 2019 at 1:54 PM Philippe Vaucher
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Konstantin Kharlamov


В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo
<[hidden email]> написал:

> On Sun, Mar 17, 2019 at 1:54 PM Philippe Vaucher
> <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Tadeus Prastowo
On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov <[hidden email]> wrote:

>
>
>
> В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo
> <[hidden email]> написал:
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Konstantin Kharlamov


В Вс, мар 17, 2019 at 4:49 ПП (PM), Tadeus Prastowo
<[hidden email]> написал:

> On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov
> <[hidden email]> wrote:
>>
>>
>>
>>  В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo
>>  <[hidden email]> написал:
>>  > 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`.



Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Tadeus Prastowo
On Sun, Mar 17, 2019 at 3:06 PM Konstantin Kharlamov <[hidden email]> wrote:

> В Вс, мар 17, 2019 at 4:49 ПП (PM), Tadeus Prastowo
> <[hidden email]> написал:
> > On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov
> > <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Stefan Monnier
In reply to this post by Philippe Vaucher
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


Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Eric Abrahamsen-2
In reply to this post by Konstantin Kharlamov
Konstantin Kharlamov <[hidden email]> writes:

> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> <[hidden email]> написал:
>> 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/


Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Eli Zaretskii
In reply to this post by Stefan Monnier
> From: Stefan Monnier <[hidden email]>
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Alex Gramiak
In reply to this post by Stefan Monnier
Stefan Monnier <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Stefan Monnier
In reply to this post by Eli Zaretskii
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Eli Zaretskii
In reply to this post by Konstantin Kharlamov
> Date: Sun, 17 Mar 2019 05:17:50 +0300
> From: Konstantin Kharlamov <[hidden email]>
> Cc: emacs-devel <[hidden email]>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [RFE] Migration to gitlab

Amin Bandali-4
In reply to this post by Eric Abrahamsen-2
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.

1234 ... 14