[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFE] Migration to gitlab
From: |
Eli Zaretskii |
Subject: |
Re: [RFE] Migration to gitlab |
Date: |
Fri, 10 May 2019 15:21:59 +0300 |
> From: 조성빈 <address@hidden>
> Date: Fri, 10 May 2019 19:37:31 +0900
> Cc: Toon Claes <address@hidden>, address@hidden, address@hidden,
> address@hidden, address@hidden
>
> > 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, Toon Claes, 2019/05/10
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/05/10
- Re: [RFE] Migration to gitlab, 조성빈, 2019/05/10
- Re: [RFE] Migration to gitlab,
Eli Zaretskii <=
- Re: [RFE] Migration to gitlab, 조성빈, 2019/05/10
- Re: [RFE] Migration to gitlab, Alex Gramiak, 2019/05/10
- Re: [RFE] Migration to gitlab, Alan Mackenzie, 2019/05/10
- Re: [RFE] Migration to gitlab, 조성빈, 2019/05/10
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/05/11
- Re: [RFE] Migration to gitlab, 조성빈, 2019/05/11
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/05/11
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/05/11
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/05/11
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/05/11