From: Thomas Huth
Found with the codespell utility.
Signed-off-by: Thomas Huth
---
docs/formatcaps.rst| 2 +-
docs/formatdomain.rst | 4 ++--
docs/glib-adoption.rst | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index da6b2
On 17/03/2025 12.29, Martin Kletzander wrote:
On Mon, Mar 17, 2025 at 11:41:20AM +0100, Thomas Huth via Devel wrote:
From: Thomas Huth
Found with the codespell utility.
If you did that typo in the subject on purpose, then hat's off to you.
Anyway, before pushing it, s/types/typos/ p
On 29/04/2025 21.48, Pierrick Bouvier wrote:
...
I'm not keen to have a default target set, but it's a personal opinion based
on fear of "implicit smart choice hurts", so I'll be happy to change my mind
with a good argument for it.
No default target, please! We've seen this with the default ma
On 29/04/2025 15.15, Daniel P. Berrangé wrote:
We remove versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the removed-features.rst document that
always has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/removed-features.rst |
On 06/05/2025 18.00, Daniel P. Berrangé wrote:
Since we deprecate and remove versioned machine types on a fixed
schedule, we can automatically ensure that the docs reflect the
latest version info, rather than requiring manual updates on each
dev cycle.
The first patch in this series removes the
On 29/04/2025 10.23, Markus Armbruster wrote:
...
I don't wish to derail this thread, but we've been dancing around the
question of how to best fix the target for some time. I think we should
talk about it for real.
Mind, this is not an objection to your larger "single binary" idea. It
could b
On 29/04/2025 15.15, Daniel P. Berrangé wrote:
We deprecate versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the deprecated.rst document that always
has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/deprecated.rst | 7 +
On 29/04/2025 15.15, Daniel P. Berrangé wrote:
When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
and deletion thresholds for versioned machine types. In such cases we need
to use the next major/minor ve
On 29/04/2025 15.15, Daniel P. Berrangé wrote:
This reverts commit c9fd2d9a48ee3c195cf83cc611b87b09f02f0013.
When we introduced the specialized machine type deprecation policy, we
allow automatic deprecation to take effect immediately, but blocked the
automatic deletion of machine types for 2 re
On 06/05/2025 18.00, Daniel P. Berrangé wrote:
When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
and deletion thresholds for versioned machine types. In such cases we need
to use the next major/minor ve
On 16/07/2025 12.54, Alex Bennée wrote:
Even with a toolchain *-user is still broken. Maybe we should just
deprecate the target. I haven't deprecated for system as we have
functional tests that work and will continue to do so.
Signed-off-by: Alex Bennée
---
docs/about/deprecated.rst | 8 +
On 30/06/2025 05.19, Collin Walling wrote:
Changelog
v5
- dropped the "none" test in qemuxmlactivetest (see commit for
details)
- reordered patches to introduce some tests first, then add
qemu.conf changes
v4
- added qemu.conf option to dictate the def
12 matches
Mail list logo
