qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deprecation of in-tree builds


From: Aleksandar Markovic
Subject: Re: deprecation of in-tree builds
Date: Sun, 22 Mar 2020 20:51:56 +0100

18:21 Ned, 22.03.2020. Peter Maydell <address@hidden> је написао/ла:
>
> On Sun, 22 Mar 2020 at 15:29, Aleksandar Markovic
> <address@hidden> wrote:
> > If the "progress" (in the form of deprecation) is so impotrant, than the authors should devise it so that there is no dammage to existing features, and no adverse effects.
> >
> > In this light, perhaps in-tree builds deorecation is 5.0 is little premature.
>
> The idea of deprecation is to give advance warning. So it's
> better for our users if we announce it earlier, rather than
> later. Strictly speaking our deprecation policy is for
> user-facing features, not build-time stuff, where we are...

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.

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.

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.

But, ok, this is just my opinion, probably unpopular within dev comunity, since it requires additional effort by us. Still, we should guide ourself with "what is right to do", and not "what is easy to do" principles.

Regards,
Aleksandar

> less strict about how much notice we give people. But it
> seems to me that if it's easy to give some advance notice
> then why shouldn't we do so?
>
> I agree that we should obviously make sure that everything
> that currently assumes an in-tree build also works with an
> out-of-tree build before we drop the support...
>
> (Also, if we don't announce that we're planning to drop
> support, nobody's going to report to us issues which
> we need to fix :-))
>
> thanks
> -- PMM
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]