[libvirt PATCH] qemu: reject readonly attribute for virtiofs

Daniel P. Berrangé berrange at redhat.com
Fri May 15 10:40:31 UTC 2020


On Wed, May 13, 2020 at 01:06:58PM +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
> 
> 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.

Ok, I'll withdraw my objection to use of full URLs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list