GitLab cross-posting to Trac?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

GitLab cross-posting to Trac?

Richard Eisenberg-4
Hi devs,

With our new GitLab workflow, will commit messages still be posted to Issues (once the migration is complete)? That's been really useful with Trac.

Thanks,
Richard
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GitLab cross-posting to Trac?

Ben Gamari-2
Richard Eisenberg <[hidden email]> writes:

> Hi devs,
>
> With our new GitLab workflow, will commit messages still be posted to
> Issues (once the migration is complete)? That's been really useful
> with Trac.
>
GitLab does not post the commit message to the issues it mentions. It
does create a link to the commit but this doesn't include the commit
message. We could change this with a daemon if we think this would be
helpful.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: GitLab cross-posting to Trac?

GHC - devs mailing list
It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)

Thanks

Simon

| -----Original Message-----
| From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg <[hidden email]>; GHC <[hidden email]>
| Subject: Re: GitLab cross-posting to Trac?
|
| Richard Eisenberg <[hidden email]> writes:
|
| > Hi devs,
| >
| > With our new GitLab workflow, will commit messages still be posted to
| > Issues (once the migration is complete)? That's been really useful
| > with Trac.
| >
| GitLab does not post the commit message to the issues it mentions. It
| does create a link to the commit but this doesn't include the commit
| message. We could change this with a daemon if we think this would be
| helpful.
|
| Cheers,
|
| - Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GitLab cross-posting to Trac?

Matthew Pickering
I really don't think we should emulate trac's behaviour here.

As from now all patches will be merged via gitlab it is unnecessary as
related merge requests show up visually on each ticket and when a
patch is merge the ticket is automatically closed. 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

On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs
<[hidden email]> wrote:

>
> It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?
>
> Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.
>
> If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)
>
> Thanks
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
> | Sent: 04 January 2019 21:33
> | To: Richard Eisenberg <[hidden email]>; GHC <[hidden email]>
> | Subject: Re: GitLab cross-posting to Trac?
> |
> | Richard Eisenberg <[hidden email]> writes:
> |
> | > Hi devs,
> | >
> | > With our new GitLab workflow, will commit messages still be posted to
> | > Issues (once the migration is complete)? That's been really useful
> | > with Trac.
> | >
> | GitLab does not post the commit message to the issues it mentions. It
> | does create a link to the commit but this doesn't include the commit
> | message. We could change this with a daemon if we think this would be
> | helpful.
> |
> | Cheers,
> |
> | - Ben
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GitLab cross-posting to Trac?

Richard Eisenberg-4
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 <[hidden email]> 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? 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?

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.

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

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.

Thanks!
Richard


On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs
<[hidden email]> wrote:

It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)

Thanks

Simon

| -----Original Message-----
| From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg <[hidden email]>; GHC <[hidden email]>
| Subject: Re: GitLab cross-posting to Trac?
|
| Richard Eisenberg <[hidden email]> writes:
|
| > Hi devs,
| >
| > With our new GitLab workflow, will commit messages still be posted to
| > Issues (once the migration is complete)? That's been really useful
| > with Trac.
| >
| GitLab does not post the commit message to the issues it mentions. It
| does create a link to the commit but this doesn't include the commit
| message. We could change this with a daemon if we think this would be
| helpful.
|
| Cheers,
|
| - Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: GitLab cross-posting to Trac?

GHC - devs mailing list

Thanks Richard – you have put it better than me.

 

It would be v helpful to have a wiki page summarising all this vocabulary, and how and under what circumstances one thing refers to another.

 

Simon

 

From: Richard Eisenberg <[hidden email]>
Sent: 05 January 2019 16:15
To: Matthew Pickering <[hidden email]>
Cc: Simon Peyton Jones <[hidden email]>; Ben Gamari <[hidden email]>; GHC <[hidden email]>
Subject: Re: GitLab cross-posting to Trac?

 

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 <[hidden email]> 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? 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?



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.



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

 

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.

 

Thanks!

Richard




On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs
<[hidden email]> wrote:


It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)

Thanks

Simon

| -----Original Message-----
| From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg <[hidden email]>; GHC <[hidden email]>
| Subject: Re: GitLab cross-posting to Trac?
|
| Richard Eisenberg <[hidden email]> writes:
|
| > Hi devs,
| >
| > With our new GitLab workflow, will commit messages still be posted to
| > Issues (once the migration is complete)? That's been really useful
| > with Trac.
| >
| GitLab does not post the commit message to the issues it mentions. It
| does create a link to the commit but this doesn't include the commit
| message. We could change this with a daemon if we think this would be
| helpful.
|
| Cheers,
|
| - Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: GitLab cross-posting to Trac?

Ben Gamari-3
In reply to this post by GHC - devs mailing list
Simon Peyton Jones <[hidden email]> writes:

> It's **super-helpful** that the Trac ticket includes, as a comment,
> the commit(s) that fixed it. Please can this happen with Gitlab too?
>
> Otherwise, when looking at the ticket two years later there is
> literally no clue what commit (if any) fixed it.
>
To be clear, GitLab does cross-reference commits and tickets. I
completely agree that this is essential functionality.

What GitLab does not do is show the entire commit message in the
ticket. It merely adds a comment mentioning the SHA of the commit.
This looks something like this [1]:

    Ernestas Kulik mentioned in commit 70166550

I can see that having the text of the commit present in the ticket
itself may have value, however.

Cheers,

- Ben


[1] https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_167754

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GitLab cross-posting to Trac?

Matthew Pickering
In reply to this post by Richard Eisenberg-4
> 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? 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?

If you mention the issue number (#12345) in the MR it will show up as
a mention on the issue.

https://gitlab.gnome.org/GNOME/nautilus/issues/434

If the commit message mentions the issue number then it shows up as a mention.

https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_119047

If a comment on another issue mentions an issue number then it shows
up as a mention.

https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_117657

>
> 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?

When a MR is merged and the commit message mentions the issue number
then a mention will be added to the issue which links the issue to the
commit.

https://gitlab.gnome.org/GNOME/nautilus/commit/70166550e89e80e91912b0e7b9bb162073042dba

https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_167754

> 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.

If you write "Closes #12345" in the MR description then when the MR is
merged it will close the issue.

https://docs.gitlab.com/ee/user/project/issues/closing_issues.html#via-merge-request

This, and not much more, is described here:
https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html

Cheers,

Matt
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GitLab cross-posting to Trac?

Ben Gamari-3
In reply to this post by Richard Eisenberg-4
Richard Eisenberg <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment