Re: [libvirt PATCH] qemu: reject readonly attribute for virtiofs
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/9c58b6eb0090b978f44299b22ff4f...
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/9c58b6eb0090b978f44299b22ff4f...
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/9c58b6eb0090b978f44299b22ff4f8d...
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/9c58b6eb0090b978f44299b22ff4f...
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.