guest OS support matrix

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Do we have any official statement about the supported guest OS versions?

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.

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.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWliGRAAoJEC3TtYFBiXSvt00QAI5ofIvp1fUd6ppueWu+w633
lqLbFpS7f9icEQOwQgizdRfJLqMDp/yP+hceVPdJr4uo79Ne/x7dMAl5iM0LKwwN
z8B9o9sQ+uBRsMbCIeLk3dvkKl6eqQl+rfgxwWM9uArmgqR+QYXiDU5uMRJ/h337
ZqXinZw2VEUFeLHNKGXONMPo83eTmPyyPq/U8J6cw+bGp606Q6RWRKFLbHD0f1Pr
Mq55PDbBPQiTpQKFSB51I0Dx6lUH+pl9VYcScGgJNHR4sVV40+u6LJBqKcDaNKX0
R2JxDVHX6MELbGiaxAFaOuMku4ellikcPP+jJU34QZz14zYR5honPcXPzYE3XFtd
3fR9osT2nUFXm9zn2S62ze31Bm16KRAfTO2EsNzaL36jdBYV35Vn3AONCZJolGsy
OXhspjSI1G+ZanE8d7RjxE5EEY3eErWrVCb7KlxMX1LbcJaHMiCxd19Ry35GV3EP
3jfjwyQd/PVsNPLTQbSKrxJ59sryArbjeyxJ3tigByjk3X0ddGIj5y9q8CHMGhF/
aJezyo6dQN8OGzWX3sx3ST1eDIka9yy+HVUfgvJzoMdbUg+AcXOIyCFuOnX+1k3F
QmPh8v3q7QRPnu1BuBYuJbDf4776PY8Nc6xwZFPXDhvRzQEc6819np1gEmA2iCwd
EoiZYguvyVq1GdGNz0AM
=RxVa
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----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-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

I strongly agree that there should be a clear, official policy on
which versions of Qubes are supported and for how long. In my opinion,
the length of the support period is not nearly as important as clearly
communicating that period, then sticking to it so that users know what
to expect and can plan accordingly. I think a shorter support period
(such as the six months you mentioned) would be reasonable for a
security-oriented OS, especially one with a smaller development team.

> 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.
>

I imagine that the majority of Qubes users, myself included, would
much rather see precious developer time devoted to fixing bugs and
adding features than to backporting patches to old versions. (Of
course, it would help to have data on how many people are still using
R2, for example.)

> 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!
>

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWlq/aAAoJEJh4Btx1RPV86VkQAMAQiueWuFvlq9aMf0Ag2W2d
4Iter64PmmrUG6TL7+ZY1mlSyJNqRXAvnkmk7R9j6f/hR8J64oBiFgDUELXSaNJZ
hDQwy24lqnhQ887QgScfmV+YyJF2q9NP2VBrlHKi8+zque/xuGUwmABZXysZuqa9
EeZEJuTpWGx5rCvRieCIdUh7HLvOxEpXlhO+Qto2PVbO4dZpP41+yH+/nTJm51oW
XCw6NLip7GYMP/gmakyEg3cpBmX4hLFgLcWnI+foErzWfG6t/Jbl7s66i53kjGxC
dsta+aV5uzNj5zkOT9mwa5F5+UW+8VCnQ53eGdPUsK+H3iPndobSlEiG2jlOF0O+
GDoxJbtMGYeVoifqaKu2DBQMBXagk8hVk9PYqF9h1KL99D7Bn4RV9SPKiU2zrExD
QJjo948PDWr04vuPbNNnC7obkDURs7dS5vfxUBTj3woZqGYXffPPU/uI6mAqZjBy
caZ5urin2lCuPbxeTcR7zKvghYfM9Z0x4we2k1rQ3MmL0pFiXQev9qWJCFzfo/j6
04kiq7ynhMbAyuWenRNKflo6ktTETWeA1LMq5x7VYP3cwUhe8N1MnCsUQJnM3/DB
o/lQi+HKFK7T1oRLk++ml8GLcbHGuKGgzDMmop+SfLictKQa5WVfsqtioIw2OaFu
JZ0Y2sJc6cLXuE3d37nV
=ppN1
-----END PGP SIGNATURE-----

[Steven]

> 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?

The second (shorter) support policy is fine for me as private user.


Best Regards

Steven

[Clemens A. Schulz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I guess a very important issue that is still open there is the missing
officially supported stable upgrade path from one release to the next
one. The website still says that it's more safe to reinstall instead
of performing an upgrade.

That's something we should resolve before thinking of forcing some
harder upgrade policy. At the moment this issue will be the reason for
many people to do not perform an upgrade from R2 to R3.0 for example.

Best Regards,
Clemens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWlr00AAoJEOx7cmrCcEBHXAIQAIujla1D2ATlx1xPYtrUd0xb
Z50WK8YlOtjE6qOgVnZ7mDzeaSTTsgHswJ0jh0em4c6PzgIDjRv+8H4aE27uBa6d
0RGCUKUp4gpyatWxyQeBgxDe9SKFb1kgkId5yV5WnmgrSV0EZotomFYUVVymZgj7
ESQ67XmbTv9fIxoIT7cOhUw6p8QdJ4OBH67fgb+jUIHgfHLL55Z7eK2TPnECAIGb
uOt22k84tLRvl1ta4HotgtTo1SUMLhoLeWAPKaL98Tusy3SWKv/SnEvNjzTUh/14
+6L6pzAtl0eYglwDo6kpt4ukstGk63h7K5kvYsRchDBx/p6tVKoUGV+AOO8K3IcE
wajFSoXlX4fX/y+I1IEXZvhZHy7odTMP2Oz2mm1z3CVWphkLT5r39UNp2QyS5o3N
CzT2oG/WPNUH/jQaB7cxbwcWfpcHatrvs1YZ5uwMXOlDo01BtfDdxfQwb0vWgN68
LFJa9WvnN5lxXVKfcH5KYV5anyg7vhK1oSPRVTPZn3yz3S6zesJDcg+8WfmQwFnV
PwlWPluSwO1pex3yLS7AcuLkN8QSaC0d78GtiuLkIglql6xtyLY5uLxRi+P4SWtF
tXkDgavO/Lwk4I/KpiyxlGTbr5wqYNCGE6Ylj5MnvhhBydzVCkRsDNveU3dJgcH9
r9uSC2whgrhwq5GUpw/R
=fFoy
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/13/2016 07:20 PM, Marek Marczykowski-Górecki wrote:

> I think the answer here is (in practice): R2: fc21 (which is no
> longer supported by Fedora)

Here I can see some problems - details below.

> R3.0: fc21, (fc22), fc23 R3.1: fc21, (fc22), fc23

Here we should follow the Fedora release schedule:

"We say maintained for approximately 13 months because the supported
period for releases is dependent on the date the release under
development goes final. As a result, Release X is supported until one
month after the release of Release X+2."
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Sch
edule

If you follow this you can drop the F21 support right now.

> 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?

6+6 months support sounds reasonable - but in addition you should keep
up with the guest OS vendor(s) as well:

The current state of R2 seems to be a dead end right now - because you
only plan to support F21 template/packages, but that has no support
from the OS vendor any more (already end of life)

So If you want to keep the R2 support till Oct 1 2016 you should
provide fedora templates/packages that are still supported by Fedora
till that time.

R3.0 and further not have any problems for now - so it is still a good
time to decide and declare :)



Regarding to forcing the users to the new versions:

The only problem source can be the 'new' release numbering.

The R3.0 for example is the official latest stable - however that is
not a real stable release - at least as I see. Mainly because it was
break some major features of R2 and we had numerous hardware
compatibility problem reports as well. And never reached the stability
and maturity of the R2 release
(That was the reason for me to step back to R2 - and stick with that
till now)





- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWlsdeAAoJEC3TtYFBiXSvC9AP/1LBzZF1t52p5DmINScRWM0Y
bMctdBAQtmNKuKcGCPb7VYu3w9gXv/VUVR9MUfSYo9wp0gHfdI7ATghREMJQT/HN
eCIxBLyhYJbr9jjUfUvo3spUfZ40h8xFSZohVAvmeiEZdBW1Db4Z+esQkVvxN3Y8
IbBYC9ZgUqU6mnPVZHO89KSI42Znui0ho38wqSY7fVuwqDJHNDwPnw3CETKTpQX7
jL6bka5oD/9M2TxIYl9sN/yKRW3iVeYJLIYAVrIpnd50wlzcZQQ4O+Pj0qOJiso/
2RKcmVpmmBge060bkAlDJpyDvWPZKI44Op4q7oWnHDlDdw8hzk6ZOuvF+eHrciIK
viYhBy37Zsps8bRwYcFcId381+PcRS41BW7ZOWd4foomMP4x54jYYYC/SR7k3l58
vlFIPsnOZp+2BPgt+nYc5zjRF3EUWpiXWVkpe8KtqNJ2wc+ujRpbg74h5EwjwpKy
VLN3qO2v1nepRNDvGXWULh1wM0BpLIazmwE6h0eAznjBdt+pHlSC2g9TccqI+gcg
5DHZfOB8DNYVs7YLoc5vC3t+J4gp7g+eqhM3u25D4a2YInBpGsnWWU/6BngpQQj8
JT88VxkHBI+zLBCOt6compU3meEw8hGAJ+gbxCFKaSC7kAyLWd0UmolUYvUtLRVD
6cJjvw6TtvsORphlIB+/
=Bm08
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/13/2016 09:10 PM, Clemens A. Schulz wrote:
> I guess a very important issue that is still open there is the
> missing officially supported stable upgrade path from one release
> to the next one. The website still says that it's more safe to
> reinstall instead of performing an upgrade.

That's should be not an issue.

I admit that the standard Qubes backup will skip some important
configs from dom0 - but in general the current upgrade method are
really fine.

And it works :)

In turn it shows that your data are located inside the private img's
and your customisations are located in the templates. The 'base
system' is replaceable any time - if you have a recent backup.





****
Real life story here:

I just made a huge mistake (1 hour before I had to make a presentation
about Qubes) by deleting ALL of my templates :D

The first 20 min was full of "oh shit I just really did it?!"
Another 10 mins was to search for "ext4 undelete" on google :)

The remaining time was still enough to just restore some (old) backup
I found in my backpack.

After this issue then the presentation went fine ;)


- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWlssuAAoJEC3TtYFBiXSvxO0P/jfgUBO1qKBhWCZYWjvZpCB9
4uSJ8OmH8YtRn8keoft+q/SBhNUTNqfjKboLyx86iv1qy0K/TTtaYUJw/gqDJ39o
20x+Xwdf2RMGnUq477vVfVMKXZ80+4ac9Nnx9ccFxfLWJ7kj6O4O7GhFHTN4HCiu
c/oX17g60VmnKDGS4/7D1yQZ+eT76ImbwTmlBx3bx4XFm3HndUrEhBH5jG18jRd1
3HX/gr8y8HSjCpGcKk0gnizvWSF9oDRGkIUvTqNkpzSDdIDGg19rrUX6rDzjOh8a
1FeE9d+qqpFs/r0Bh4ok6DE+FvyOWNdjCJ78FFilcC3utLvUkRbfAURrXJ9T/RlY
H69e6OqSlNK8rjMY8fsv7XGeCdmKQJSmOLRvzQo6N2NWjpxBbzxImsfkiE6lihAf
TH/w9NXJzbu7RFOIymZwKtpLm/0vkUFx915VN/kj9JSVRO4zfgyopXDNH15Osqbr
G+FSr2hlK9Pio1OXCsogy/taRBdxvAIABhDnm2iYstapwL7lms3XJHifcaLwlfOv
ftNMQbl82NpgWZvmxZp0PVWsCLcxgujlSTYdH6XkZFdIRM/VWhDU//6Cp5zBB//9
nQa7uyjMGBHGhxi02FCw/08U30fipATHi8qdnAJHcKZbdeKQGSgdMyYdZB5zwdVV
ISEmI3pwDiSTG+zddhw4
=2y8F
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> 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.

That table would be useful in the documentation.

Yes, best to not support that many with excessive testing. For example
on Debian, just jessie. And moving on to stretch once that gets close to
the new stable.

>> 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?

Go short. I am amazed how productive you are, but loading too much
maintenance work on you for old versions is not great. You know best how
much effort it generates. Go shorter. Long time support versions are
enterprise features. So interested enterprises should pay for this. As a
user of a security focused distribution, I am more interested in latest
security rather than old versions. Ultimately up to the Qubes Council.

Cheers,
Patrick

[Joanna Rutkowska]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

+1 for what Patrick is saying about the long term support being more of a
pay-for-it feature.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWl3fhAAoJEDOT2L8N3GcYMlkQAMgPkyrv8nmbzaamx77mJt6R
viqJdpZCdTtvYIJH1rQcxoOP4YkaJT2HtSikj4ta3I2xJVDD+j6ZHWskA8Itr+hd
9yPRa/jdNG+P74q4smDL6Jrfin06MRy8rXiUGGXtRS7VDrsMuFLxlcNorE/o5zls
o+eB9py7/2suPcxToJMst8QAdympLseHO8tQcvHoZ51fCIGiUYTBbiKB07l7J74G
uMD7vgOjpBXghYltVdh3b7XpLY/Flnk4wJnGyHG691/JlNKYW7cQvD3tl01aEiDw
12e5XPjNnRFCAjbX+LMlXJLf01/4sC0cM9XWtUUyn8RJYKZIlvgE47bcgdEhtWAE
briEaWfAoUDaUeRwVjnQIUeDODDeqaM3AvKJOcPMoJ4QWJ5cjqfMRYbYDjmGXDPf
phsVByhzgekNgbbt60MzCoH0TqhHbs4av/QGVnum4UGLCnJI+VfiRVMYkh3QN4Kj
5FQP04FflpAeW0+QuTPN0KdcODG7LNVsf4v6jNxP1qksD2bjcYO2QRupk0cTxhTz
XotbQseJDpWHBu6S8tXOx3Mw7OpeZbbWAylblOf0nltva0iz+YtQXZXFUIqkj/Xf
D1HXsK5GGF4GdcBZRojEDJFYSnaDpcTyBATwuxzx5LHOjdnEDP7bNcFC6MVE1IIe
o3658moJJqhwMCVmbalu
=hkeu
-----END PGP SIGNATURE-----

[Jeremias E.]

Hello,

Qubes is a user oriented desktop operating system with a focus on security.
In my opinion clear communication which Qubes OS is currently supported
in the qubes homepage is really important. Additionally the supported guest OS
versions should be mentioned.

The table for Qubes OS could look like:

| Qubes OS 1 | outdated |
| Qubes OS 2 | outdated |
| Qubes OS 3 | f20 | stable (recommended) |
| Qubes OS 3.1-rc1 | f20 | outdated |
| Qubes OS 3.1-rc2 | f20 | testing |
| Qubes OS 3.1 | f20 | future stable |
| Qubes OS 4.0-alpha | fXX | in development |

Qubes OS guests for stable (3.0) and testing (3.1):

Fedora:
Fedora 23 (stable)

Debian
Debian 8.2 "Jessie" (stable)
Debian 9 "Stretch" (future - testing)

Whonix:
Whonix XZ (Debian XY)

Archlinux:
--> rolling release

Windows:
Win 7 + Qubes Tools 3.xx

I think supporting outdated linux distributions should not be the goal of Qubes - Development Team.
Furthermore the guest OS versions should be outdated according to the distribution release cycles
and not be dependent on the Qubes OS versions. This is right now nevertheless the case.

From my experience Qubes users does not switch, based on the time. They switch if a specific feature is
complete.
To decide when to mark Qubes 4.0 as stable and Qubes 3.1 to outdated I would recommend explaining
which features are completed in Qubes 4.0 instead of using a time based (months) cycle.
One of the biggest issue for many users to switch from Qubes 2.0 to Qubes 3.0 was the lack of
Windows guest OS support. This shows clearly that most of the upgrade decisions are based on
features instead of time.

I share the same opinion on LTS releases as Patrick Schleizer does.

Best regards
  J. Eppler

[Holger Levsen]

Hi,

sorry to chime in so late…

On Mittwoch, 13. Januar 2016, Marek Marczykowski-Górecki wrote:
> Actually we don't have even official statement about which Qubes
> versions are supported...
> We should work on it, thanks for bringing it up!

absolutly.

> > 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)

I think documenting this on the webpage would be great.

> I think we should have some clear policy on that.

absolutly. I think having such a policy and documenting it, is even more
important than what the policy is exactly ;-) (well… within limits…)

> 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.

[...]

> 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?

sounds great.

> 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?

support RHEL/CentOS as well? Those have long term support.

> 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!

I think this would also be good to have mentioned on the webpage and/or
elsewhere so it stays visible.



BTW, some people have mentioned paid long term support for Qubes, I'm not sure
how this can work in practice, because (most of) Qubes is GPL licenced,
meaning if you distribute the binaries, you have to provide sources to anyone
who's asking. Hm, now that I write it I see how this could: provide binaries
for money only, but provide free sources to everyone… people who are
interested in running LTS versions are probably also happy not having to
compile things themselves…


cheers,
Holger

[Jeremias E.]

Hello,

BTW, some people have mentioned paid long term support for Qubes, I'm not sure
how this can work in practice, because (most of) Qubes is GPL licenced,
meaning if you distribute the binaries, you have to provide sources to anyone
who's asking. Hm, now that I write it I see how this could: provide binaries
for money only, but provide free sources to everyone… people who are
interested in running LTS versions are probably also happy not having to
compile things themselves…

the idea is pretty easy and used by many open source software companies. The idea is
that the software is open source, but if you want to have support a specific guest or qubes
os version for a long time and you still want to get security patches and other stuff, you
simply pay for the service of backporting or for direct telephone/email support.
Basically you are paid for the support service or let's say this in other words, you get
paid for helping a company with their infrastructure.

Debian 8 will be supported for at least three years, means Debian is a LTS version, but does
not have it in it's name. Ubuntu needed the LTS model, because they release every 6 months
a new version, but it is difficult for companies to change their system every 6 months, that is
the simple reason for the LTS versions in Ubuntu.

Best regards
  J. Eppler

[Holger Levsen]

Hi,

cc:s dropped as I'm only replying to a rather off-topic bit here… :)

On Donnerstag, 28. Januar 2016, Jeremias E. wrote:
> Debian 8 will be supported for at least three years, means Debian is a LTS
> version, but does
> not have it in it's name.

while over the last >10 years one could say that Debian stable was supported
for 3 years, the underlying the rule is: Debian oldstable will get support
until a year after Debian stable has been released. And as Debian has also
been very stable in releasing every two years, it's basically the case that a
stable release is supported for 3 years.

But, now there is also Debian LTS, which get's an additional 2 years support.

Well, at least that was the case now the first time with Debian 7 LTS and
currently this is also the plan for Debian 8 and 9. More information is
available on https://wiki.debian.org/LTS

;tl;dr: Debian 9 (jessie) LTS will receive support until spring 2020, so five
years.


cheers,
Holger

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Jan 27, 2016 at 02:02:32PM +0100, Holger Levsen wrote:
> Hi,
>
> sorry to chime in so late…
>
> On Mittwoch, 13. Januar 2016, Marek Marczykowski-Górecki wrote:
> > Actually we don't have even official statement about which Qubes
> > versions are supported...
> > We should work on it, thanks for bringing it up!
>
> absolutly.
>
> > > 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)
>
> I think documenting this on the webpage would be great.
>
> > I think we should have some clear policy on that.
>
> absolutly. I think having such a policy and documenting it, is even more
> important than what the policy is exactly ;-) (well… within limits…)

Thanks to Axon, it is already here:
https://www.qubes-os.org/doc/supported-versions/

> > 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.
> [...]
> > 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?
>
> sounds great.
>
> > 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?
>
> support RHEL/CentOS as well? Those have long term support.

That may be an option, but as always, it boils down to someone doing
that port...

> > 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!
>
> I think this would also be good to have mentioned on the webpage and/or
> elsewhere so it stays visible.

Yes, good idea
https://github.com/QubesOS/qubes-issues/issues/1700

> BTW, some people have mentioned paid long term support for Qubes, I'm not sure
> how this can work in practice, because (most of) Qubes is GPL licenced,
> meaning if you distribute the binaries, you have to provide sources to anyone
> who's asking. Hm, now that I write it I see how this could: provide binaries
> for money only, but provide free sources to everyone… people who are
> interested in running LTS versions are probably also happy not having to
> compile things themselves…

Jeremias already answered this - I totally agree.

- --
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

iQEcBAEBCAAGBQJWqX3PAAoJENuP0xzK19csuHMIAIfb1dVHBdJBQv/CJ/PZryHd
g/he2haQXP4IuVyMylGACXocFqhwh0EX7PTwTLFBqq03jL2v9jbZ+M9imLvF5B3y
fH8xsmzXZhz1ZjOP7PRtylwoZ58dL6UdUEkteyDczt2MuSmzA7z7J4BIEx+tFWjp
FSrG6Y03j6T+P0bR/Tth/Uz4eWSPdocIAo32waK0w5S28dDBvyk008VeZVNLw9hA
AwtWul9Z8PQ0Hdu4IcSwaA4j61H6Uy7pvo3pyiB7Ur1RVSIKPhBSsFhriCZVzicj
j9Xbv1evq/chu7k1uPq3pecQU0mkTMjTQZno0OzGXa/g5702IlAVufw253mNOQM=
=mdrN
-----END PGP SIGNATURE-----

[Holger Levsen]

Hi,

On Donnerstag, 28. Januar 2016, Marek Marczykowski-Górecki wrote:
> Thanks to Axon, it is already here:
> https://www.qubes-os.org/doc/supported-versions/

cool!

> > BTW, some people have mentioned paid long term support for Qubes, I'm not
> > sure how this can work in practice, because (most of) Qubes is GPL
> > licenced, meaning if you distribute the binaries, you have to provide
> > sources to anyone who's asking.

> Jeremias already answered this - I totally agree.

I havent replied to that one aspect Jeremias ignored (I think), but if you
offer updates for GPL software for money and you give it to anyone, you also
have to give the sources for these updates to anyone asking for them *for
free*. Of course you can still ask for money for the binaries…

Just saying.


cheers,
Holger

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, of course. And it isn't a problem for a lot of businesses (RH for
example), so shouldn't be either for us.
Anyway *currently* we don't offer paid LTS.

- --
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

iQEcBAEBCAAGBQJWqsMTAAoJENuP0xzK19csZdQH/RGdz6kyvSJc52Mj4SoQ6woH
JcYQMCVTgflm7zRwIJmotzBeg/Ylop2w87surLyO6kyBpPvpJw5PAHIdsX6Chz96
JIVgIwfGoeNRuzrN9Nx5WmoD9iMH0Ad51lwpJdt5XWyZbHIySos28a+Vt6hyfDlD
o7wmKQrJcMKgCyJc95IuXqGKGnj1cU3tyvfo57ZN+RIvgbHJEZ2/W/5Cj9YahGyj
GC0XnVn0IFm3l0FV7ZivgFHWMgjEta+ipSIlXVREVgfNQVwSyR+fZLNlZSn60W87
4WzEuSifXROJrbGyQMSvz1Rw5NuCQVjfdq40zp33LTZlnXIi6SBmB9sNY+JQv6o=
=FYB4
-----END PGP SIGNATURE-----

[Holger Levsen]

Hi,

 

On Freitag, 29. Januar 2016, Marek Marczykowski-Górecki wrote:

> Yes, of course. And it isn't a problem for a lot of businesses (RH for

> example), so shouldn't be either for us.

 

right, or couse, as you said :) Sometimes RedHat is leading by really good example, which my Debian centric head sometimes forgets. Thanks for reminding me!

 

> Anyway *currently* we don't offer paid LTS.

 

Anyway, you still rock! (Though I can see how that doesn't feed anyone yet.)

 

 

cheers,

Holger