On Tue, Feb 28, 2017 at 08:39:07PM +0100, Lennart Poettering wrote: > On Tue, 28.02.17 19:28, Daniel P. Berrange (berrange@xxxxxxxxxx) wrote: > > The problem with splitting these rules out into a separate project > > is that there's no other existing place that they would live. The > > "virtio people" as a group merely write specifications. The actual > > implementation of those specs is done by multiple other independant > > groups - QEMU (for host side, though other host side impls exist > > too) and Linux (for guest side). The udev rules are Linux guest > > support pieces, but of course Linux itself doesn't distribute udev > > rules - it delegated that job to the udev package hence why they > > are here currently. So I don't see that pushing the rules out of > > the udev repo would be beneficial to people building VMs. Yeah, that's my view too. Those by-path symlinks are parts of the basic functionality of the system, and it'd be unfortunate to require yet another package to make them appear. We've been there, done that, and too much fragmentation causes more issues than it solves. The issue with those patches seems to be that it's hard to find knowledgeable people to review them, but telling those people to start a project of their own doesn't really help with that, it just pushes the work around while adding overhead. > The thing is simply that for these kinds of things it's not done with > drive-by patches simply because we have noone right now who can review > them with the right technical expertise. > > So yeah, I am not totally against leaving them in the udev repo (Or to > say this differently, I am much more interested to see the scsi stuff > go somewhere else than the virtion stuff), but only if somebody steps > up and takes up ownership of this, and does so continously. > > No, this doesn't mean you have to subscribe to all systemd > PRs/issues. It just means that this someone will react to being /cc'ed > in the github repo sooner or later, and say something. We could keep an informal list of people who care about specific areas. This already functions to some extent, and we should just be more consistent: for any issue, see who touched the code recently, and mention them in the PR or issue, and for PRs, add people to the reviewers list. Github the social coding site, ftw! Zbyszek _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
