On Wed, May 13, 2020 at 13:06:58 +0200, Peter Krempa wrote: > On Wed, May 13, 2020 at 11:20:07 +0100, Daniel Berrange wrote: > > On Wed, May 13, 2020 at 12:05:44PM +0200, Peter Krempa wrote: > > > On Wed, May 13, 2020 at 10:57:33 +0100, Daniel Berrange wrote: > > > > On Wed, May 13, 2020 at 11:51:50AM +0200, Peter Krempa wrote: > > [...] > > > > > The point is for libvirt to follow normal practice from GitLab, so that > > > > contributors don't have to know about libvirt specific rules for contributing > > > > to the project. Telling users to change the normal issue syntax into a URL > > > > whenever they send a patch is not something we should be doing. > > > > > > Even if they are flawed?! Just mentioning a random number in the commit > > > message may be nice for people looking at the code via web-ui. That is > > > nice but you can't do much there. But I and many other look at the code > > > in the local checkout and 'git' doesn't randomly decide to expand the > > > number to the gitlab uri and make it clickable. > > > > > > Now if I'd like to look at the issue after some time I'll e.g. when > > > going through git-blame I'll have to open the browser, open gitlab, find > > > the project and find the issue rather than just click a link. That's > > > stupid. If gitlab can't deal with the link, it's frankly broken and we > > > should not give in to a broken approach just because everybody else > > > does. > > > > It isn't about giving in. Again the point is to not needlessly create > > special rules for contributing to libvirt, because every special rule > > we add is another thing for contributors to stumble over. Some rules > > are worth it because they have meaningful benefits such as the use of > > Signed-off-by/DCO. The mentioning of full URLs instead of the normal > > issue reference syntax does not have a meaningful benefit that > > justifies a libvirt special rule for contributions. > > I gave an examples of two specific meaningful benefit above: > > 1) it provides a clickable link without second guessing where to go for > command line users > 2) provides stable reference to the hosting of issues > > Note that for example github uses exactly the same format for > referencing issues. That means that it's unclear what we are referring. > > Just observe the following behaviours on the commit that was just pushed > and Jano helpfully for this demonstration included both versions: > > 1) gitlab: libvirt/libvirt > > https://gitlab.com/libvirt/libvirt/-/commit/9c58b6eb0090b978f44299b22ff4f8d3be3a240f > > Here I'd expect a clickable link but there isn't one. I have no idea > why. > > You can see that gitlab doesn't recognize it. I'm not sure whether the > format Jano chose is bad, but this already enforces some kind of form we > need to conform to. > > 2) gitlab: pipo.sk/libvirt > > https://gitlab.com/pipo.sk/libvirt/-/commit/9c58b6eb0090b978f44299b22ff4f8d3be3a240f > > Unsurprisingly it doesn't work here, but the full link is shortened and > still points to the correct issue. > > 3) github: libvirt/libvirt > > https://github.com/libvirt/libvirt/commit/9c58b6eb0090b978f44299b22ff4f8d3be3a240f > > As expected #23 points to nothing, but the full link still points to the > issue even cross-hosting. > > 4) github: pipo/libvirt (plus I've created 23 test issues in my fork) > > https://gitlab.com/pipo.sk/libvirt/-/commit/9c58b6eb0090b978f44299b22ff4f8d3be3a240f Oops, messed up the most interesting one: https://github.com/pipo/libvirt/commit/9c58b6eb0090b978f44299b22ff4f8d3be3a240f > > Now this is fun. '#23' points to the local issue #23 in my fork while > the full link still points to the issue. > > > The shortened issue names are ambiguous and the hosting has no way in > figuring out where to point to. Providing full URL is not something > which should be described as "no meaningful benefit" but it actively > disambiguates the links regardless of where it's hosted or refered from. >
