-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jan 13, 2016 at 10:06:10AM +0000, Zrubi wrote:
> Hi,
>
> Do we have any official statement about the supported guest OS versions?
Actually we don't have even official statement about which Qubes
versions are supported...
We should work on it, thanks for bringing it up!
> Where supported means you (ITL/Qubes developers) provide qubes related
> packages for a specific Qubes release.
>
> I mainly interested about fedora releases - but the same info would be
> helpful about other distributions as well for sure.
I think the answer here is (in practice):
R2: fc21 (which is no longer supported by Fedora)
R3.0: fc21, (fc22), fc23
R3.1: fc21, (fc22), fc23
And for Debian it would be:
R3.0: (wheezy) jessie
R3.1: (wheezy) jessie (stretch)
In parentheses I've put versions for which we publish the packages, but
don't do excessive testing.
> And because we have more than one supported Qubes versions and more
> than one guest OS distributions/versions we should have create a
> compatibility/support matrix.
>
> Right now the docs only talking about ITL supported vs Community
> supported templates - but not about OS versions.
I think we should have some clear policy on that. For both supporting a
Qubes versions and VM templates. Some proposition:
We support (release updates with bug fixes) for the most recent Qubes
stable version and for the previous stable version up until a year after
releasing the current one.
This would mean:
R3.0: supported, not end date set yet (will be a year after releasing
R3.1)
R2: supported until Oct 1 2016 - a year after releasing R3.0
Generally IMO we should encourage users to upgrade to newest available
version, so maybe even harder policy, like:
- full support up to 6 months after releasing the next stable release
- security fixes only, within next 6 months
What do you all think about it?
Then it goes to supporting OS versions. Here we have additional factor
of upstream support. For Debian it isn't a problem (or rather:
limitation), because of quite long support. But for Fedora it may be.
Any proposition here?
Technically we are trying for every patch to first go into "master"
branch, which means most recent development version, and only after
testing there, backport it into stable releases. This means the more
time some old release is supported, the harder such operation becomes.
This also means that backporting support for newer OS version to old
Qubes version (like fc23 support for R2) may be a hard task.
And BTW ideally we'd like to have Stable Release Manager, who would
classify which patches deserve such backport and would do it. So, if
anyone is interested in helping us here, please let us know!
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWlqORAAoJENuP0xzK19csuyMH/02AUmVDIVcf20eUW/GJOtiL
qcxX9digGDK+ZkHylT/Nw8gWqj9i8HtdNeZHsyH22a9pkpcy25zzZzXQDijuFPuE
uLJni7j3xPCD18aQgymY5urq1W0prreWHUL+SWb6nS3r5yzruHaotZD5IlmI7knw
5+MZtT4S5quvkXj5fCqw2W4yWdcSESLIGC6UFUb1WB/ONrQGYzcsApSZKz9uWndA
pwQixj7p4CUrkxPeo4dvessnLHqNURZMdigeGmfIFB7VuicMgGMRPfnOgfrSCPyU
ilUQCKSYT0O/L3N/SbjkDiWtMXxh4R47qTMx6qCRYdWGgf4vs1xyBJYkY2SfMvs=
=XjzI
-----END PGP SIGNATURE-----