[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] guest OS support matrix
From:       Axon <axon () openmailbox ! org>
Date:       2016-01-13 20:13:17
Message-ID: 5696AFDD.7020404 () openmailbox ! org
[Download RAW message or body]

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

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

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

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/5696AFDD.7020404%40openmailbox.org. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]