GitLab cross-posting to Trac?
ben at well-typed.com
Sat Jan 5 22:03:01 UTC 2019
Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> I second Simon's "super-helpful". But we don't need to exactly copy
> Trac's behavior. If there is a clear link to the e.g. commit with
> message, that's fine too.
>> On Jan 5, 2019, at 3:47 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>> As from now all patches will be merged via gitlab it is unnecessary as
>> related merge requests
> We're not using GitLab ticketing yet, but I understand we will. When
> you say "related merge requests", does that include *issues*?
> GitHub does this, so I imagine it does, but we should make sure. In
> other words, if we make an MR that references an issue, will the issue
> show this fact? What if the MR text doesn't reference an issue, but
> the commit message does?
In both cases a note will be left on the referenced issue.
> For example, many of my patches are targeted toward one issue, but fix
> several others on the way. The MR text will probably mention only the
> main issue, but the commit message will mention the others. Will the
> others automatically be cross-referenced? Or will I be forced to copy
> these auxiliary issues into the MR text for proper cross-referencing?
> I believe in GitHub, the cross-referencing happens at *mentions*.
> I think that means we would get it upon posting the MR and upon the
> use of an issue number in a comment. But does anything happen at a
> *merge*? That is, suppose the fix for #12345 gets posted and debated
> at some length. The #12345 issue will get linked to the MR. Then, all
> is ready and we click the "merge when green" button. Some hours later,
> the MR is merged. Does the issue get updated then?
Yes, when the commit is merged to master a note of the form "mentioned
in commit abcde" will appear on the issue. The SHA is a link and the
commit title is shown when one hovers over it.
>> show up visually on each ticket and when a
>> patch is merge the ticket is automatically closed.
> By "ticket", do you mean issue or MR? I assume you mean MR, and I like
> this behavior. But I hope you don't mean issue. It's quite common to
> push a patch materially affecting an issue but not closing it, and I
> think the manual step to close the issue separately is worthwhile.
By default GitLab can automatically close issues mentioned by a commit
pushed to the `master` branch. However, not all mentioned will result in
closure; rather, only those matching one of a set of patterns .
I personally find the default set of patterns a bit scary. For instance,
I found that a commit containing the string "doesn't fix #NNNN" actually
results in #NNNN being closed . For this reason I think we really want to
change or entirely disable  this behavior.
>> Ticket numbers mentioned in commits also create references from
>> tickets to commits so you can click the hash to see what the commit
>> https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655 <https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655>
> One small point of nomenclature I'd like to clarify/propose:
> - Merge Request (MR): A proposed patch. The new form of a Phab Diff.
> - Issue: An infelicity or task to be completed. The new form of a Trac Ticket.
> - Ticket: ?. I propose: Either an MR or an issue.
Hmm, I generally have used "ticket" and "issue" interchangeably. I
suppose we could repurpose it as you propose; I'm not sure which is less
confusing. In general I think I will probably just avoid using the term
after the migration.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs