On Sun, 22 Mar 2020 at 19:52, Aleksandar Markovic <aleksandar.qemu.de...@gmail.com> wrote: > If an end-user feature works only in in-tree builds (so, > explitely said: not in out-of-tree builds), this is not > a build-time stuff, but user-facing feature issue.
gprof is a developer feature, not an end-user-facing feature. By the latter I mean "some feature that users who have installed a built binary might be using": command line stuff, actual functionality in the QEMU binary, QMP protocol, that kind of thing. > If someone is keen on removing any feature (as is truly in this case), I > expect at least some moderate investigation being done on what could be > affected (prior to announcing deprecation), rather than attitude "ok, let's > announce deprecation, see if someone start clamoring, and, if not, we are > good to go with removing". For me, this slightly disappointing. Before you told me about the gprof issue, the *only* thing I was aware of that might break was the coverity scan build, which is a purely project internal bit of infrastructure. >From my point of view, we did the investigation, in the sense that for years we have had out-of-tree as our standard recommended way of building QEMU and the thing we test in our CI. Anything that breaks out-of-tree is by definition something that fell through the gaps in our CI and which we couldn't know about unless somebody tells us about it. The "announce deprecation" part is the final part of the process, and sometimes it does, yes, result in somebody saying "you missed this thing", because we know our CI is far from perfect. > I haven't seen anyone doing a sufficiently thourough analysis >on what happens without in-tree builds, and doesn't work in >out-of-tree builds in a proper way. *Everything* is supposed to work in out of tree builds. If it doesn't that's a bug -- unless people report bugs we'll never know to fix them. Most developers use out of tree builds and all our CI is out of tree builds, so they actually get better ad-hoc and CI coverage than in-tree. Out-of-tree is overwhelmingly what we build and what we test, so it's in-tree that breaks more often and where I'd expect to find more things we didn't realise were broken. To be clear, I'm not saying we should pull the rug out from anybody. I'm saying: * we should clearly say what our plans are, with a long warning if we can reasonably give longer warning * if there's anything that we would accidentally be breaking with those plans, we should adjust the plans so we don't break things we didn't mean to break This doesn't seem controversial to me... thanks -- PMM