* Avi Kivity <avi@xxxxxxxxxx> wrote: > >> [...] Second, from my point of view all contributors are volunteers > >> (perhaps their employer volunteered them, but there's no difference from > >> my perspective). Asking them to repaint my apartment as a condition to > >> get a patch applied is abuse. If a patch is good, it gets applied. > > > > This is one of the weirdest arguments i've seen in this thread. Almost all > > the time do we make contributions conditional on the general shape of the > > project. Developers dont get to do just the fun stuff. > > So, do you think a reply to a patch along the lines of > > NAK. Improving scalability is pointless while we don't have a decent GUI. > I'll review you RCU patches > _after_ you've contributed a usable GUI. > > ? What does this have to do with RCU? I'm talking about KVM, which is a Linux kernel feature that is useless without a proper, KVM-specific app making use of it. RCU is a general kernel performance feature that works across the board. It helps KVM indirectly, and it helps many other kernel subsystems as well. It needs no user-space tool to be useful. KVM on the other hand is useless without a user-space tool. [ Theoretically you might have a fair point if it were a critical feature of RCU for it to have a GUI, and if the main tool that made use of it sucked. But it isnt and you should know that. ] Had you suggested the following 'NAK', applied to a different, relevant subsystem: | NAK. Improving scalability is pointless while we don't have a usable | tool. I'll review you perf patches _after_ you've contributed a usable | tool. you would have a fair point. In fact, we are doing that we are living by that. It makes absolutely zero sense to improve the scalability of perf if its usability sucks. So where you are trying to point out an inconsistency in my argument there is none. > > This is a basic quid pro quo: new features introduce risks and create > > additional workload not just to the originating developer but on the rest > > of the community as well. You should check how Linus has pulled new > > features in the past 15 years: he very much requires the existing code to > > first be top-notch before he accepts new features for a given area of > > functionality. > > For a given area, yes. [...] That is my precise point. KVM is a specific subsystem or "area" that makes no sense without the user-space tooling it relates to. You seem to argue that you have no 'right' to insist on good quality of that tooling - and IMO you are fundamentally wrong with that. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
