Mailing List Archive

Xen 4.16 development update; request for regression bug reports
The mainline development branch of Xen is has taken the first step
towards stabilisation for 4.16: new features not yet submitted, at
least in draft form, will now be deferred to the following release.

We aim to make each Xen release as good as possible, and that includes
high quality and particularly an absence of serious regressions.
To help deliver this as Release Manager for Xen 4.16, I need the help
of the Xen developer and user community

In particular, please would users and developers make sure that I know
about:

* Regressions in the current development branch (xen-unstable)
compared to Xen 4.15;

* Major or important work which is targeted for 4.16, but at risk
of missing the deadlines.

Please email me, CC xen-devel (as in the Reply-To), and of course
other interested parties. including the maintainer(s) of relevant
subsystems (if you know who that would be).

Thanks for your attention,
Ian.


Planned release schedule for Xen 4.16 (recap):

Friday 24th September PASSED Last posting date

Patches adding new features should be posted to the mailing list
by this cate, although perhaps not in their final version.
(3 weeks)

Friday 15th October Feature freeze

Patches adding new features should be committed by this date.
Straightforward bugfixes may continue to be accepted by
maintainers.
(3 weeks)

Friday 5th November **tentatve** Code freeze

Bugfixes only, all changes to be approved by the Release Manager,
on the basis of a (progressively stricter[*]) risk assessment.
(2 weeks)

Friday 19th November **tentative** Hard code freeze [*]

Bugfixes for serious bugs (including regressions), and low-risk
fixes only.
(0.5 weeks)

Tuesday 23rd November **tentative** Branch off staging-4.16

xen-unstable open again - with caveats to avoid release disruption.
(1.5 weeks)

Friday 3rd December **tentative** Final commits (docs/prep only)
Week of 6th December **tentative** Release
(probably Tuesday or Wednesday)

Any patches containing substantial refactoring are to treated as
new features, even if they intent is to fix bugs.

Freeze exceptions will not be routine, but may be granted in
exceptional cases for small changes (on the basis of risk assessment,
like any release-ack). Large series will not get exceptions.
Contributors *must not* rely on, or expect, a freeze exception, or
release schedule slip.

If as a feature proponent you feel your feature is at risk and there
is something the Xen Project could do to help, please consult me or
ask here on xen-devel. In such situations please reach out earlier
rather than later. I will try to put you in touch with people who may
be able to help.

[*] The distinction between Code Freeze and Hard Code Freeze is a
matter of degree, not kind; the Hard Code Freeze data and associated
tighter policy text is indicative rather than normative.