On 12/12/19 8:25 AM, George Dunlap wrote:
On Mon, Dec 2, 2019 at 5:08 PM Kevin Stange kevin@steadfast.net wrote:
I don't really think we should drop a release before its security support ends, unless we have *really clear* communication to repo users as to the life cycles of these builds in advance.
Indeed, the purpose of this email is in fact to make such a clear communication. Citrix (i.e., Anthony & I) have committed to providing up-to-date packages for one version at a time; this is meant to give people input into which version that is. The Virt SIG cannot as a whole commit to supporting releases until security support ends unless others step up and make commitments to do so.
We should probably provide a matrix of which Xen versions are offered by the SIG, who is maintaining them, and when they will last be supported (roughly if it's not 100% clear due to upstream scheduling).
There's a bunch of legacy Xen4CentOS and other confusing Xen docs in the CentOS documentation that need to be cleaned up, removed, or unified.
I'm happy to continue working on and testing releases for whichever branch I'm currently on (which is 4.8 right now, but I'm moving on since upstream is done with security support). However I can't make commitments to support or test versions I am not actively running in production, nor provide specific life cycle guarantees. I made that mistake with 4.4, though meltdown was an extenuating circumstance; I simply couldn't handle that kind of backport myself.
That said, I *may* offer continued support and testing for 4.12 when 4.14's release pushes it out of maintenance by Virt SIG. That's something I'm going to have to play by ear, I guess.
I don't want to burden Steven Haigh any, but I wonder if there's a way we could combine some of our efforts to make both "Xen made easy!" and the Virt SIG Xen easier to manage.