|
From: | Dmitry Gutov |
Subject: | Re: "If you're still seeing problems, please reopen." [Was: bug#25148:] |
Date: | Thu, 21 Nov 2019 17:15:43 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 21.11.2019 17:09, João Távora wrote:
On 21.11.2019 17:00, João Távora wrote:But in the GitLab/GitHub model, there is that main repository, which is your duty to protect, and also isolated from it, one for each "JR Random Hacker", a_fork_ (maybe Gitlab calls it a "clone") that JR can randomly hack away in.I wanted to say this myself, but then tried forking in EMBA. And that process is still stuck. So apparently forking is slow in GitLab: https://gitlab.com/groups/gitlab-org/-/epics/607This is a problem, as cheap forks are a cornerstone of this model.
We can try using it. All depends on how many such contributors we get. The fork is completed now, lives here as an example: https://emba.gnu.org/dgutov/emacs
Of course, it's not as effortless as on GitHub, unfortunately.
In other words, in my view, it doesn't make much sense to migrate to GitLab's issue tracker without the integration with the forking system. Presuming that integration is similar to Github's, of course.
I disagree, naturally. We don't have a "PR workflow" now, so we won't lose anything by not enabling MR functionality for casual contributors. The bug tracker alone is better than Debbugs from a random user's point of view.
[Prev in Thread] | Current Thread | [Next in Thread] |