Richard Eisenberg <[email protected]> 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 <[email protected]> >> 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 [1]. 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 [2]. For this reason I think we really want to change or entirely disable [3] this behavior. [1] https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/55970 [3] https://docs.gitlab.com/ee/administration/issue_closing_pattern.html >> Ticket numbers mentioned in commits also create references from >> tickets to commits so you can click the hash to see what the commit >> was. >> >> 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. Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
