Re: [RFE] Migration to gitlab

[조성빈 <pcr910303@icloud.com>]

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.