* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote: > > > > None of the perf developers with whom i'm working complained > > about the shared repo so far - publicly or privately. By all > > means they are enjoying it and if you look at the stats and > > results you'll agree that they are highly productive working in > > that environment. > > Just because you brought it up. > > I personally find it awkward to work in the linux tools directory. > Maybe this is the reason that I haven't been such a big contributor > of perf. [...] Well, this is an argument with a long history we've had from the moment we started perf - i think the main underlying reason for that is that you still see perf as competition to ftrace instead of seeing perf the child of ftrace, the next version of ftrace, the next iterative step of evolution :-/ Unfortunately there's not much that i can do about that beyond telling you that you are IMHO wrong - you as the main ftrace developer thinking that it's competition is a self-fulfilling expectation. Eventually someone will do the right thing and implement 'perf trace' (there's still the tip:tmp.perf/trace2 prototype branch) and users will flock to that workflow because it's so much more intuitive in practice. From what i've seen from the short prototype experiments i've conducted it's a no-brainer superior workflow and design. > [...] I only pushed ktest into the kernel tools directory because > people convinced me to do so. Having it there didn't seem to bring > in many other developers. [...] It was somewhat similar with perf - contributors only arrived after it went upstream, and even then with a delay of a few releases. Also, and it pains me to have to mention it, but putting a .pl script into the kernel repo is not necessarily a reciepe for attracting a lot of developers. We went to great lengths to kill the .cc perf report file in perf, to keep the programming environment familiar to kernel developers and other low level utility folks. Also, obviously a tool has to be important, interesting and has to offer a distinct edge over other tools to attract contributors. Maybe tools/testing/ktest/ does not sound that interesting? Naming also matters: i sure would have moved it to tools/ktest/, its name already suggests that it's about testing, why repeat that twice? Sounds weird. In that sense tools/kvm/ is better than perf: it has already attracted a core group of good, productive contributors despite still being an out of tree fork. The point here was that Pekka & co not just clearly enjoys working on tools/kvm/ and has no trouble attracting contributors, but also *relies* on it being in the kernel tree. 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
