On 2/18/23 10:27, Markus Armbruster wrote:
This one is valid. Still, it's a "want", not a "must have". If it was
a hard "must have", then CentOS 8 support would be in trouble: no mypy
out of the box, as far as I can tell.
Right, and in fact this is by design: these tools move too fast for a
On 2/17/23 16:29, Daniel P. Berrangé wrote:
* it introduces different support periods for*native* vs.*non-native*
dependencies. Non-native dependencies are currently Python ones only,
and for simplicity the policy only mentions Python; however, the concept
generalizes to other language
Daniel P. Berrangé writes:
> On Fri, Feb 17, 2023 at 01:41:50PM +0100, Paolo Bonzini wrote:
[...]
>> This proposed update to the support policy chooses the last of these
>> possibilities. It does by modifying two aspects of the support policy:
>>
>> * it introduces different support periods f
Paolo Bonzini writes:
> Historically, the critical dependency for both building and running
> QEMU has been the distro packages. Because QEMU is written in C and C's
> package management has been tied to distros (at least if you do not want
> to bundle libraries with the binary, otherwise I supp
On Fri, Feb 17, 2023 at 01:41:50PM +0100, Paolo Bonzini wrote:
> Historically, the critical dependency for both building and running
> QEMU has been the distro packages. Because QEMU is written in C and C's
> package management has been tied to distros (at least if you do not want
> to bundle libr
Historically, the critical dependency for both building and running
QEMU has been the distro packages. Because QEMU is written in C and C's
package management has been tied to distros (at least if you do not want
to bundle libraries with the binary, otherwise I suppose you could use
something like