Dropping support for old templates
98 views
Skip to first unread message
Marek Marczykowski-Górecki
Nov 30, 2018, 6:07:06 PM11/30/18
to qubes-devel, Andrew David Wong, Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
[moved discussion from ticket #2065]
On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer wrote:
> Is it possible to make changes in Qubes packages only affecting Debian releases equal or greater than 9?
>
> Inability to do so would make development difficult. Not a secret that I am not a big fan of carrying around oldstable versions support. Lot effort for little to zero popularity? I'd not release new Qubes packages for debian-8 in order to not break them. Only debian-9 and above. Otherwise too many targets required to test / too much development effort, imo.
Actually the same problem applies to Fedora, with an exception that many
of those templates are not even supported upstream anymore (in contrast
to oldstable, which is still part of Debian LTS, until 2020).
So here are actually two questions:
1. Do we want to stop publishing new packages for templates not
supported upstream anymore?
2. Do we want to stop publishing new packages for old templates still
supported upstream?
I think the answer for the first one should be "YES". Look at the insane
count of Fedora versions for R3.2 on supported-versions[1].
We just need a process for doing that:
- an announcement? we had already some[2]
- some method for marking this on supported-versions page (simply
remove version? or should we retain what were initially supported?)
In fact, I've already went ahead and disabled building packages for old
Fedora versions[3], mostly to reduce build time. Oh, Fedora 27 upstream
support ends today, so we could drop this one from the list too. And
post a reminder to migrate to Fedora 28 (or have we already done it? I
can't find it).
Now, about the second question. It is about Debian 8 and Whonix 13
(based on Debian 8). Since Debian 8 was included originally
in both Qubes 3.2 and 4.0, many people surely do use it. I don't have
hard numbers for that (in theory we could collect such stats from our
updates server, but we don't do that right now). Since Debian 8 still
has upstream security support, there is no security-based reason for
dropping it. But as Patrick said, it makes it difficult to maintain.
Especially since Debian 8 is much older than oldest supported Fedora...
This already lead to one major problem:
https://github.com/QubesOS/qubes-issues/issues/4443
In theory, automated testing could help here. We already have a lot of
tests, and actually the problem linked above would be detected by it.
But we don't have automation to run those tests on all the supported
configurations _automatically_. It is still manual process (either on
some developer machine, or on our OpenQA instance). I think we're not
far from such setup:
- we have tests,
- we have where to run them,
- we need a script to run them automatically (periodically? when new
packages are uploaded to testing?)
- and automatic reporting back to updates-status issues - to spot the
problem and not move broken packages to stable
But in this very moment it isn't done yet.
As we can see, none of the users with testing repositories enabled
spotted the problem in time either.
So, I'm slightly leaning towards dropping support for Debian 8. But want
to hear other opinions too.
[1] https://www.qubes-os.org/doc/supported-versions/
[2] https://www.qubes-os.org/news/2018/05/23/fedora-26-and-debian-8-approaching-eol/
[3] https://github.com/QubesOS/qubes-builder/commit/fb6be23df2b4707ed83a98a635bd508972d39363
- --
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-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlwBwpMACgkQ24/THMrX
1yzwzggAiopOVqsBB89DZ+Ky4gJZ76quW242Pm/U/gGkEXjubMyjWazSzvqdS3/b
MNiQsFI117yKX+ShmJXOqb+YaG4UoqnfbPrxynQqr1LZFtEq+3u8w8C4jMS/zC93
unxNO0f9mC5LfWbwJLzfVFseFzEUoBp3cVQSYdgycWXxlSrkBq2dQ3SRhPBbWmS2
ZPbf5ah1tsPlEP0MTWxv94/NGLMaug63FqGALvhrBtMIbBPRAyFsbqlkMkVn5Rj0
uyqj3C6m9m7+CqY8gjhaqJn/PVxXPA9hwswKcctbUa3/kZr1/9LFMofQvPP1gnHp
+uv9IQ5Dp2HmV94A3tOU492a5sLGkQ==
=yLpO
-----END PGP SIGNATURE-----
Hash: SHA256
[moved discussion from ticket #2065]
On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer wrote:
> Is it possible to make changes in Qubes packages only affecting Debian releases equal or greater than 9?
>
> Inability to do so would make development difficult. Not a secret that I am not a big fan of carrying around oldstable versions support. Lot effort for little to zero popularity? I'd not release new Qubes packages for debian-8 in order to not break them. Only debian-9 and above. Otherwise too many targets required to test / too much development effort, imo.
Actually the same problem applies to Fedora, with an exception that many
of those templates are not even supported upstream anymore (in contrast
to oldstable, which is still part of Debian LTS, until 2020).
So here are actually two questions:
1. Do we want to stop publishing new packages for templates not
supported upstream anymore?
2. Do we want to stop publishing new packages for old templates still
supported upstream?
I think the answer for the first one should be "YES". Look at the insane
count of Fedora versions for R3.2 on supported-versions[1].
We just need a process for doing that:
- an announcement? we had already some[2]
- some method for marking this on supported-versions page (simply
remove version? or should we retain what were initially supported?)
In fact, I've already went ahead and disabled building packages for old
Fedora versions[3], mostly to reduce build time. Oh, Fedora 27 upstream
support ends today, so we could drop this one from the list too. And
post a reminder to migrate to Fedora 28 (or have we already done it? I
can't find it).
Now, about the second question. It is about Debian 8 and Whonix 13
(based on Debian 8). Since Debian 8 was included originally
in both Qubes 3.2 and 4.0, many people surely do use it. I don't have
hard numbers for that (in theory we could collect such stats from our
updates server, but we don't do that right now). Since Debian 8 still
has upstream security support, there is no security-based reason for
dropping it. But as Patrick said, it makes it difficult to maintain.
Especially since Debian 8 is much older than oldest supported Fedora...
This already lead to one major problem:
https://github.com/QubesOS/qubes-issues/issues/4443
In theory, automated testing could help here. We already have a lot of
tests, and actually the problem linked above would be detected by it.
But we don't have automation to run those tests on all the supported
configurations _automatically_. It is still manual process (either on
some developer machine, or on our OpenQA instance). I think we're not
far from such setup:
- we have tests,
- we have where to run them,
- we need a script to run them automatically (periodically? when new
packages are uploaded to testing?)
- and automatic reporting back to updates-status issues - to spot the
problem and not move broken packages to stable
But in this very moment it isn't done yet.
As we can see, none of the users with testing repositories enabled
spotted the problem in time either.
So, I'm slightly leaning towards dropping support for Debian 8. But want
to hear other opinions too.
[1] https://www.qubes-os.org/doc/supported-versions/
[2] https://www.qubes-os.org/news/2018/05/23/fedora-26-and-debian-8-approaching-eol/
[3] https://github.com/QubesOS/qubes-builder/commit/fb6be23df2b4707ed83a98a635bd508972d39363
- --
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-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlwBwpMACgkQ24/THMrX
1yzwzggAiopOVqsBB89DZ+Ky4gJZ76quW242Pm/U/gGkEXjubMyjWazSzvqdS3/b
MNiQsFI117yKX+ShmJXOqb+YaG4UoqnfbPrxynQqr1LZFtEq+3u8w8C4jMS/zC93
unxNO0f9mC5LfWbwJLzfVFseFzEUoBp3cVQSYdgycWXxlSrkBq2dQ3SRhPBbWmS2
ZPbf5ah1tsPlEP0MTWxv94/NGLMaug63FqGALvhrBtMIbBPRAyFsbqlkMkVn5Rj0
uyqj3C6m9m7+CqY8gjhaqJn/PVxXPA9hwswKcctbUa3/kZr1/9LFMofQvPP1gnHp
+uv9IQ5Dp2HmV94A3tOU492a5sLGkQ==
=yLpO
-----END PGP SIGNATURE-----
Chris Laprise
Nov 30, 2018, 7:25:20 PM11/30/18
to Marek Marczykowski-Górecki, qubes-devel, Andrew David Wong, Patrick Schleizer
support lifespan that the distro offers. In general, ending support
prematurely is destabilizing; PC users shouldn't be forced into
rapid-change environments if it can be avoided.
Long term support is one of the main advantages of offering Debian. (The
other two main advantages over Fedora are larger software library and
fully-signed repositories.)
Conversely, one of the things that makes using Fedora so annoying is the
relentless (often trivial and buggy) updates for about 2/3 of its
'always young' lifecycle, then having to do OS upgrades after only 12-15
months of use.
With that said, I don't think long-term Debian support should
necessarily apply to Whonix, which is its own distro in a sense.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
unman
Nov 30, 2018, 8:16:27 PM11/30/18
to qubes-devel
LTS for Debian.
Whonix 13 already lacks suport from WhonixQubes, so perhaps it should
be dropped from Qubes support also - although as there appear to be
a number of issues affecting the update to 14 it might be best to see
those resolved first before dropping Qubes support.
unman
Andrew David Wong
Nov 30, 2018, 11:05:38 PM11/30/18
to Marek Marczykowski-Górecki, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 11/30/18 7:16 PM, unman wrote:
> On Fri, Nov 30, 2018 at 07:25:15PM -0500, Chris Laprise wrote:
>> On 11/30/2018 06:06 PM, Marek Marczykowski-Górecki wrote:
>>> [moved discussion from ticket #2065]
>>>
>>> On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer wrote:
>>>> Is it possible to make changes in Qubes packages only affecting Debian releases equal or greater than 9?
>>>>
>>>> Inability to do so would make development difficult. Not a secret that I am not a big fan of carrying around oldstable versions support. Lot effort for little to zero popularity? I'd not release new Qubes packages for debian-8 in order to not break them. Only debian-9 and above. Otherwise too many targets required to test / too much development effort, imo.
>>>
>>> Actually the same problem applies to Fedora, with an exception that many
>>> of those templates are not even supported upstream anymore (in contrast
>>> to oldstable, which is still part of Debian LTS, until 2020).
>>>
>>> So here are actually two questions:
>>> 1. Do we want to stop publishing new packages for templates not
>>> supported upstream anymore?
>>> 2. Do we want to stop publishing new packages for old templates still
>>> supported upstream?
>>>
>>> I think the answer for the first one should be "YES". Look at the insane
>>> count of Fedora versions for R3.2 on supported-versions[1].
>>> We just need a process for doing that:
>>> - an announcement? we had already some[2]
An announcement would be absolutely necessary. (We should never silently
drop support for anything, ever.)
Just [2] would be insufficient, since it's just about the upstream
distros going EOL. We have to explicitly say Qubes is ending support, as
distinct from the upstream maintainer ending support. Cf:
https://www.qubes-os.org/news/2018/10/05/whonix-support-ending-for-qubes-32/#whonix-support-for-qubes-os
>>> - some method for marking this on supported-versions page (simply
>>> remove version? or should we retain what were initially supported?)
>>>
I'd prefer to retain what was initially supported and indicate when
Qubes support ended.
>>> In fact, I've already went ahead and disabled building packages for old
>>> Fedora versions[3], mostly to reduce build time. Oh, Fedora 27 upstream
>>> support ends today, so we could drop this one from the list too. And
>>> post a reminder to migrate to Fedora 28 (or have we already done it? I
>>> can't find it).
>>>
Done:
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/
I'm inclined to agree with Chris and unman. As I mentioned on #4443,
Qubes has never dropped support for a TemplateVM before its upstream
distro reached EOL. I'd like to see us maintain that track record of
reliability.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwCCH0ACgkQ203TvDlQ
MDDKnRAAtYTV74GV7vnjsmS9XQijWRiy4SQKgULF2dE9qLIU0uO9Iq22WChcuZMr
SedWRt91vAPjXKM5VegZJISRLxmuW3j3K3kaomHGATdQZo2wvvAZ/6X7mdiUlRT/
orxRvRmXhA3oDLGYpBCAwJzNyn8j3r95XjXs1jnnXGpayaMiEHpG8OENQKrhfMcZ
c9MpSPi7mT29C11GkCTB2kWL1WjzyVdIpFG4f6+xlFrfplN6C+umnExMI1wqB2xf
z5u+mQOdluPunjzJX7SrtEqcwFIpOXOXcg8WiwdQK2d+8FiJvhZ6wej/w3AqNgwN
1hovBrj07CVj2z6kUPaOyoFafAdjBNdnSAEciSgUvsBTRHtUNlrFdkNF1woz8OXa
csqKVBjrvvCvptWabUfu78/uihJqLwTOH4LvG4F990GC47bbGzG02lmPgusC5NaJ
fPik8X2uIAhlhW4Y7ueyN1ltje9XN3XUp+OrLlxrOXBiLldM9aLoQV7N/ZKOMmjG
7Hqe4M14fV59cMDlAgmRoN0vWojVtntpKeMx5rNar/zE8/h4VRA41GEIfANbv+vr
OGjXb74M89ZPHL9A4ZYEHs2rZJBUB1Fnl7BrEDG3l3r8fIvuWS9SEf7sUH/3Vn+F
F/ITx6lvNNZG9ssq/sVgiRDIpapBZWswzYSbv8o5DRGAKQu0A80=
=T8bH
-----END PGP SIGNATURE-----
Hash: SHA512
On 11/30/18 7:16 PM, unman wrote:
> On Fri, Nov 30, 2018 at 07:25:15PM -0500, Chris Laprise wrote:
>> On 11/30/2018 06:06 PM, Marek Marczykowski-Górecki wrote:
>>> [moved discussion from ticket #2065]
>>>
>>> On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer wrote:
>>>> Is it possible to make changes in Qubes packages only affecting Debian releases equal or greater than 9?
>>>>
>>>> Inability to do so would make development difficult. Not a secret that I am not a big fan of carrying around oldstable versions support. Lot effort for little to zero popularity? I'd not release new Qubes packages for debian-8 in order to not break them. Only debian-9 and above. Otherwise too many targets required to test / too much development effort, imo.
>>>
>>> Actually the same problem applies to Fedora, with an exception that many
>>> of those templates are not even supported upstream anymore (in contrast
>>> to oldstable, which is still part of Debian LTS, until 2020).
>>>
>>> So here are actually two questions:
>>> 1. Do we want to stop publishing new packages for templates not
>>> supported upstream anymore?
>>> 2. Do we want to stop publishing new packages for old templates still
>>> supported upstream?
>>>
>>> I think the answer for the first one should be "YES". Look at the insane
>>> count of Fedora versions for R3.2 on supported-versions[1].
>>> We just need a process for doing that:
>>> - an announcement? we had already some[2]
drop support for anything, ever.)
Just [2] would be insufficient, since it's just about the upstream
distros going EOL. We have to explicitly say Qubes is ending support, as
distinct from the upstream maintainer ending support. Cf:
https://www.qubes-os.org/news/2018/10/05/whonix-support-ending-for-qubes-32/#whonix-support-for-qubes-os
>>> - some method for marking this on supported-versions page (simply
>>> remove version? or should we retain what were initially supported?)
>>>
Qubes support ended.
>>> In fact, I've already went ahead and disabled building packages for old
>>> Fedora versions[3], mostly to reduce build time. Oh, Fedora 27 upstream
>>> support ends today, so we could drop this one from the list too. And
>>> post a reminder to migrate to Fedora 28 (or have we already done it? I
>>> can't find it).
>>>
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/
Qubes has never dropped support for a TemplateVM before its upstream
distro reached EOL. I'd like to see us maintain that track record of
reliability.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwCCH0ACgkQ203TvDlQ
MDDKnRAAtYTV74GV7vnjsmS9XQijWRiy4SQKgULF2dE9qLIU0uO9Iq22WChcuZMr
SedWRt91vAPjXKM5VegZJISRLxmuW3j3K3kaomHGATdQZo2wvvAZ/6X7mdiUlRT/
orxRvRmXhA3oDLGYpBCAwJzNyn8j3r95XjXs1jnnXGpayaMiEHpG8OENQKrhfMcZ
c9MpSPi7mT29C11GkCTB2kWL1WjzyVdIpFG4f6+xlFrfplN6C+umnExMI1wqB2xf
z5u+mQOdluPunjzJX7SrtEqcwFIpOXOXcg8WiwdQK2d+8FiJvhZ6wej/w3AqNgwN
1hovBrj07CVj2z6kUPaOyoFafAdjBNdnSAEciSgUvsBTRHtUNlrFdkNF1woz8OXa
csqKVBjrvvCvptWabUfu78/uihJqLwTOH4LvG4F990GC47bbGzG02lmPgusC5NaJ
fPik8X2uIAhlhW4Y7ueyN1ltje9XN3XUp+OrLlxrOXBiLldM9aLoQV7N/ZKOMmjG
7Hqe4M14fV59cMDlAgmRoN0vWojVtntpKeMx5rNar/zE8/h4VRA41GEIfANbv+vr
OGjXb74M89ZPHL9A4ZYEHs2rZJBUB1Fnl7BrEDG3l3r8fIvuWS9SEf7sUH/3Vn+F
F/ITx6lvNNZG9ssq/sVgiRDIpapBZWswzYSbv8o5DRGAKQu0A80=
=T8bH
-----END PGP SIGNATURE-----
Chris Laprise
Dec 1, 2018, 3:07:37 PM12/1/18
to unman, qubes-devel, Marek Marczykowski-Górecki
months until EOL) instead of 9.
Although I'd prefer that Debian be supported past oldstable through its
LTS phase, I understand what a burden that is to a small project like Qubes.
And in the specific Debian 8 case, an announcement about EOL was already
made. IMHO it was also a temperamental version that encompassed a
problematic era in Linux userspace, so if it were my decision and I
wanted to start supporting Debian LTS to the five-year mark I wouldn't
start that policy until version 9.
Patrick Schleizer
Dec 6, 2018, 9:58:43 PM12/6/18
to qubes...@googlegroups.com
Marek Marczykowski-Górecki:
I mean, what's lost if we don't?
> I think the answer for the first one should be "YES". Look at the insane
> count of Fedora versions for R3.2 on supported-versions[1].
> We just need a process for doing that:
> - an announcement? we had already some[2]
> - some method for marking this on supported-versions page (simply
> remove version? or should we retain what were initially supported?)
Perhaps QVMM could show and visually(!) mark template packages as
obsolete? This visual mark should be removable after the user upgraded.
Perhaps a dom0 one time popup with a reminder? Using
/etc/qubes/post-install.d/ mechanism?
That would hint users at having to upgrade.
> In fact, I've already went ahead and disabled building packages for old
> Fedora versions[3], mostly to reduce build time. Oh, Fedora 27 upstream
> support ends today, so we could drop this one from the list too. And
> post a reminder to migrate to Fedora 28 (or have we already done it? I
> can't find it).
Yes.
> Now, about the second question. It is about Debian 8 and Whonix 13
> (based on Debian 8). Since Debian 8 was included originally
> in both Qubes 3.2 and 4.0, many people surely do use it. I don't have
> hard numbers for that (in theory we could collect such stats from our
> updates server, but we don't do that right now). Since Debian 8 still
> has upstream security support, there is no security-based reason for
> dropping it. But as Patrick said, it makes it difficult to maintain.
> Especially since Debian 8 is much older than oldest supported Fedora...
>
> This already lead to one major problem:
> https://github.com/QubesOS/qubes-issues/issues/4443
>
> In theory, automated testing could help here. We already have a lot of
> tests, and actually the problem linked above would be detected by it.
Even if detected, it's still a burden to develop stuff in a way being
compatible with old versions.
> [moved discussion from ticket #2065]
>
> On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer wrote:
>> Is it possible to make changes in Qubes packages only affecting Debian releases equal or greater than 9?
>
>> Inability to do so would make development difficult. Not a secret that I am not a big fan of carrying around oldstable versions support. Lot effort for little to zero popularity? I'd not release new Qubes packages for debian-8 in order to not break them. Only debian-9 and above. Otherwise too many targets required to test / too much development effort, imo.
>
> Actually the same problem applies to Fedora, with an exception that many
> of those templates are not even supported upstream anymore (in contrast
> to oldstable, which is still part of Debian LTS, until 2020).
>
> So here are actually two questions:
> 1. Do we want to stop publishing new packages for templates not
> supported upstream anymore?
> 2. Do we want to stop publishing new packages for old templates still
> supported upstream?
Both, yes.
>
> On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer wrote:
>> Is it possible to make changes in Qubes packages only affecting Debian releases equal or greater than 9?
>
>> Inability to do so would make development difficult. Not a secret that I am not a big fan of carrying around oldstable versions support. Lot effort for little to zero popularity? I'd not release new Qubes packages for debian-8 in order to not break them. Only debian-9 and above. Otherwise too many targets required to test / too much development effort, imo.
>
> Actually the same problem applies to Fedora, with an exception that many
> of those templates are not even supported upstream anymore (in contrast
> to oldstable, which is still part of Debian LTS, until 2020).
>
> So here are actually two questions:
> 1. Do we want to stop publishing new packages for templates not
> supported upstream anymore?
> 2. Do we want to stop publishing new packages for old templates still
> supported upstream?
I mean, what's lost if we don't?
> I think the answer for the first one should be "YES". Look at the insane
> count of Fedora versions for R3.2 on supported-versions[1].
> We just need a process for doing that:
> - an announcement? we had already some[2]
> - some method for marking this on supported-versions page (simply
> remove version? or should we retain what were initially supported?)
obsolete? This visual mark should be removable after the user upgraded.
Perhaps a dom0 one time popup with a reminder? Using
/etc/qubes/post-install.d/ mechanism?
That would hint users at having to upgrade.
> In fact, I've already went ahead and disabled building packages for old
> Fedora versions[3], mostly to reduce build time. Oh, Fedora 27 upstream
> support ends today, so we could drop this one from the list too. And
> post a reminder to migrate to Fedora 28 (or have we already done it? I
> can't find it).
> Now, about the second question. It is about Debian 8 and Whonix 13
> (based on Debian 8). Since Debian 8 was included originally
> in both Qubes 3.2 and 4.0, many people surely do use it. I don't have
> hard numbers for that (in theory we could collect such stats from our
> updates server, but we don't do that right now). Since Debian 8 still
> has upstream security support, there is no security-based reason for
> dropping it. But as Patrick said, it makes it difficult to maintain.
> Especially since Debian 8 is much older than oldest supported Fedora...
>
> This already lead to one major problem:
> https://github.com/QubesOS/qubes-issues/issues/4443
>
> In theory, automated testing could help here. We already have a lot of
> tests, and actually the problem linked above would be detected by it.
compatible with old versions.
Andrew David Wong
Dec 6, 2018, 10:29:56 PM12/6/18
to Patrick Schleizer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 12/6/18 8:58 PM, Patrick Schleizer wrote:
> Marek Marczykowski-Górecki:
>> [moved discussion from ticket #2065]
>>
>> On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer
>> wrote:
>>> Is it possible to make changes in Qubes packages only
>>> affecting Debian releases equal or greater than 9?
>>
>>> Inability to do so would make development difficult. Not a
>>> secret that I am not a big fan of carrying around oldstable
>>> versions support. Lot effort for little to zero popularity?
>>> I'd not release new Qubes packages for debian-8 in order to
>>> not break them. Only debian-9 and above. Otherwise too many
>>> targets required to test / too much development effort, imo.
>>
>> Actually the same problem applies to Fedora, with an exception
>> that many of those templates are not even supported upstream
>> anymore (in contrast to oldstable, which is still part of Debian
>> LTS, until 2020).
>>
>> So here are actually two questions: 1. Do we want to stop
>> publishing new packages for templates not supported upstream
>> anymore? 2. Do we want to stop publishing new packages for old
>> templates still supported upstream?
>
> Both, yes.
>
> I mean, what's lost if we don't?
>
In the case of (2), what's lost is reliable support for TemplateVMs
from the user's point of view. We'd be forcing users to upgrade on our
schedule, sooner than they'd have to if they were just using the
upstream distro normally. This isn't to say that we definitely
shouldn't do it. I'm simply answering the question of "what's lost if
we don't?" There is certainly something lost. The question is whether
the value of what's gained outweighs the value of what's lost.
>> I think the answer for the first one should be "YES". Look at
>> the insane count of Fedora versions for R3.2 on
>> supported-versions[1]. We just need a process for doing that: -
>> an announcement? we had already some[2] - some method for
>> marking this on supported-versions page (simply remove version?
>> or should we retain what were initially supported?)
>
> Perhaps QVMM could show and visually(!) mark template packages as
> obsolete? This visual mark should be removable after the user
> upgraded. Perhaps a dom0 one time popup with a reminder? Using
> /etc/qubes/post-install.d/ mechanism?
>
> That would hint users at having to upgrade.
>
This is a great idea. Users shouldn't have to rely on seeing an
announcement from me in order to know that they have to update
something. The more of this external communication we can integrate
into Qubes in a secure way, the more robust and self-sufficient the
system will be.
Related: https://github.com/QubesOS/qubes-issues/issues/3430
(This doesn't mean we'll stop publishing announcements the way we
currently do. We'd probably continue our current announcements to
provide out-of-band verification and for those who want to be notified
via email, RSS, or social media on non-Qubes devices.)
Feature requested: https://github.com/QubesOS/qubes-issues/issues/4581
>> In fact, I've already went ahead and disabled building packages
>> for old Fedora versions[3], mostly to reduce build time. Oh,
>> Fedora 27 upstream support ends today, so we could drop this one
>> from the list too. And post a reminder to migrate to Fedora 28
>> (or have we already done it? I can't find it).
>
> Yes.
>
>> Now, about the second question. It is about Debian 8 and Whonix
>> 13 (based on Debian 8). Since Debian 8 was included originally
>> in both Qubes 3.2 and 4.0, many people surely do use it. I don't
>> have hard numbers for that (in theory we could collect such
>> stats from our updates server, but we don't do that right now).
>> Since Debian 8 still has upstream security support, there is no
>> security-based reason for dropping it. But as Patrick said, it
>> makes it difficult to maintain. Especially since Debian 8 is
>> much older than oldest supported Fedora...
>>
>> This already lead to one major problem:
>> https://github.com/QubesOS/qubes-issues/issues/4443
>>
>> In theory, automated testing could help here. We already have a
>> lot of tests, and actually the problem linked above would be
>> detected by it.
>
> Even if detected, it's still a burden to develop stuff in a way
> being compatible with old versions.
>
MDCzQQ/+OzoY5Byjz9uTnyxQn44Ujy16SFaL0ncfiu/S56sGtYe8ubQaUoh9gUBw
f98vQVmwZx6T+9vCyCTCEuSy/XXh6NKicN5tjBH72SY/gdSMSy8Bgu87mTtKxPMv
TEG4wDr5OOpgtE7bMxGwugtMCA1aeBYATGjxcKRZmXOYm8nAHvB651o8ek4cpHVR
7V9ZSm/GT8sswfjOtcEqpxOQnuKLghYEpwndZp3AnVfG+vAKEyswv1n7WQELldB9
jXu7Q5iJE1XM6mA52idrWqBr5JB8OmcfTtezS+VgEjC252sVqdSqYe62zQCG9BYm
/b5xTgq25wkyPRwvhNTbWW1N1qNzYze1ASMQK7dJIbLXjUw/b8xuE1NFm2QFGyOb
DiqJ7sdmaeIlzVYJ6phSwTfLFMHYpaRC7sgR/S5YS0OZt2Mgwhf6NYbcESyH7o1u
WrWHpXiUku7AlUMEJBrkLamEXFh1AnsninM6XMmQxPzaXWQib+RNhf6qJJ4fiPYs
Lc6SG7Mh4kc2SgW5OAdrNhoePPRDCcpOOHy6vCOJb58wVKeeiXOBxSEGF/aE9SIL
sFZpPE88Fnx5wFeuSDOHRBFbohK+3sVDDsYPC9W04k58UbYl2CVS5onKVZ2tX1w+
gqriSD0hI6DqR2OXL8Ey8UbDlzUs24T1uNT62InMX8VdEuYRH4c=
=M62n
-----END PGP SIGNATURE-----
Hash: SHA512
On 12/6/18 8:58 PM, Patrick Schleizer wrote:
> Marek Marczykowski-Górecki:
>> [moved discussion from ticket #2065]
>>
>> On Fri, Nov 30, 2018 at 11:44:21AM +0000, Patrick Schleizer
>> wrote:
>>> Is it possible to make changes in Qubes packages only
>>> affecting Debian releases equal or greater than 9?
>>
>>> Inability to do so would make development difficult. Not a
>>> secret that I am not a big fan of carrying around oldstable
>>> versions support. Lot effort for little to zero popularity?
>>> I'd not release new Qubes packages for debian-8 in order to
>>> not break them. Only debian-9 and above. Otherwise too many
>>> targets required to test / too much development effort, imo.
>>
>> Actually the same problem applies to Fedora, with an exception
>> that many of those templates are not even supported upstream
>> anymore (in contrast to oldstable, which is still part of Debian
>> LTS, until 2020).
>>
>> So here are actually two questions: 1. Do we want to stop
>> publishing new packages for templates not supported upstream
>> anymore? 2. Do we want to stop publishing new packages for old
>> templates still supported upstream?
>
> Both, yes.
>
> I mean, what's lost if we don't?
>
from the user's point of view. We'd be forcing users to upgrade on our
schedule, sooner than they'd have to if they were just using the
upstream distro normally. This isn't to say that we definitely
shouldn't do it. I'm simply answering the question of "what's lost if
we don't?" There is certainly something lost. The question is whether
the value of what's gained outweighs the value of what's lost.
>> I think the answer for the first one should be "YES". Look at
>> the insane count of Fedora versions for R3.2 on
>> supported-versions[1]. We just need a process for doing that: -
>> an announcement? we had already some[2] - some method for
>> marking this on supported-versions page (simply remove version?
>> or should we retain what were initially supported?)
>
> Perhaps QVMM could show and visually(!) mark template packages as
> obsolete? This visual mark should be removable after the user
> upgraded. Perhaps a dom0 one time popup with a reminder? Using
> /etc/qubes/post-install.d/ mechanism?
>
> That would hint users at having to upgrade.
>
announcement from me in order to know that they have to update
something. The more of this external communication we can integrate
into Qubes in a secure way, the more robust and self-sufficient the
system will be.
Related: https://github.com/QubesOS/qubes-issues/issues/3430
(This doesn't mean we'll stop publishing announcements the way we
currently do. We'd probably continue our current announcements to
provide out-of-band verification and for those who want to be notified
via email, RSS, or social media on non-Qubes devices.)
Feature requested: https://github.com/QubesOS/qubes-issues/issues/4581
>> In fact, I've already went ahead and disabled building packages
>> for old Fedora versions[3], mostly to reduce build time. Oh,
>> Fedora 27 upstream support ends today, so we could drop this one
>> from the list too. And post a reminder to migrate to Fedora 28
>> (or have we already done it? I can't find it).
>
> Yes.
>
>> Now, about the second question. It is about Debian 8 and Whonix
>> 13 (based on Debian 8). Since Debian 8 was included originally
>> in both Qubes 3.2 and 4.0, many people surely do use it. I don't
>> have hard numbers for that (in theory we could collect such
>> stats from our updates server, but we don't do that right now).
>> Since Debian 8 still has upstream security support, there is no
>> security-based reason for dropping it. But as Patrick said, it
>> makes it difficult to maintain. Especially since Debian 8 is
>> much older than oldest supported Fedora...
>>
>> This already lead to one major problem:
>> https://github.com/QubesOS/qubes-issues/issues/4443
>>
>> In theory, automated testing could help here. We already have a
>> lot of tests, and actually the problem linked above would be
>> detected by it.
>
> Even if detected, it's still a burden to develop stuff in a way
> being compatible with old versions.
>
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwJ6R4ACgkQ203TvDlQ
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
MDCzQQ/+OzoY5Byjz9uTnyxQn44Ujy16SFaL0ncfiu/S56sGtYe8ubQaUoh9gUBw
f98vQVmwZx6T+9vCyCTCEuSy/XXh6NKicN5tjBH72SY/gdSMSy8Bgu87mTtKxPMv
TEG4wDr5OOpgtE7bMxGwugtMCA1aeBYATGjxcKRZmXOYm8nAHvB651o8ek4cpHVR
7V9ZSm/GT8sswfjOtcEqpxOQnuKLghYEpwndZp3AnVfG+vAKEyswv1n7WQELldB9
jXu7Q5iJE1XM6mA52idrWqBr5JB8OmcfTtezS+VgEjC252sVqdSqYe62zQCG9BYm
/b5xTgq25wkyPRwvhNTbWW1N1qNzYze1ASMQK7dJIbLXjUw/b8xuE1NFm2QFGyOb
DiqJ7sdmaeIlzVYJ6phSwTfLFMHYpaRC7sgR/S5YS0OZt2Mgwhf6NYbcESyH7o1u
WrWHpXiUku7AlUMEJBrkLamEXFh1AnsninM6XMmQxPzaXWQib+RNhf6qJJ4fiPYs
Lc6SG7Mh4kc2SgW5OAdrNhoePPRDCcpOOHy6vCOJb58wVKeeiXOBxSEGF/aE9SIL
sFZpPE88Fnx5wFeuSDOHRBFbohK+3sVDDsYPC9W04k58UbYl2CVS5onKVZ2tX1w+
gqriSD0hI6DqR2OXL8Ey8UbDlzUs24T1uNT62InMX8VdEuYRH4c=
=M62n
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages