Re: deprecation of in-tree builds

[Peter Maydell]

On Sun, 22 Mar 2020 at 19:52, Aleksandar Markovic
<address@hidden> 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