[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFE] Migration to gitlab
From: |
Alan Mackenzie |
Subject: |
Re: [RFE] Migration to gitlab |
Date: |
Sat, 11 May 2019 02:12:06 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Alex.
On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
> Eli Zaretskii <address@hidden> 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, 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, 2019/05/10
- 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 <=
- 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
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/05/11
- Re: [RFE] Migration to gitlab, Basil L. Contovounesios, 2019/05/11
- Re: [RFE] Migration to gitlab, Basil L. Contovounesios, 2019/05/11