Qubes User Forum
an unofficial Proof of Concept project

Home » Mailing Lists » qubes-devel » More regular point releases schedule?
More regular point releases schedule? [message #2798] Wed, 06 February 2019 16:54 Go to next message
Marek Marczykowski-Go
Messages: 92
Registered: October 2018
Karma: 0
Member
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

It may be a good idea to introduce regular schedule for stable [point
releases[1]. It would minimize the need to download a lot of updates
just after installation. This is even more significant, if some updates
may require non-standard update procedure (like installing new template
versions). Such releases should also be coordinated with relevant
templates maintainers.

I'm not sure what such schedule should look like, every 3 months? 6 months?

Any opinions?

[1] https://www.qubes-os.org/doc/version-scheme/#release-version .

- --
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/THMrX1ywFAlxbEUUACgkQ24/T HMrX
1yy8Ngf+PG4qVZyTgXxEHdxHFkLZF/ak5w98GT6x06GcekQqnoNbagx/0AKv a+qS
CqL11gcKiI/K6ml9dqIkpa0Vvuy+Mw0aUp13vo6qraohXj2JlCmZrr1HCuPD 7Jef
sOcXzMk965VovdibmWqsynfFgPe7yf85jQXqWVvhcVn/t+C5BbvHrXSpb+wv A5DR
CUYm1oLr4R0FfwOqd1pcWHGuWneBPFSLv2q5TpExFNZGZBaIlOaSvIEza2ev OXYu
X5HQFFh0E6y1E3kN4jkwEsGn+Cv2cZsW/dWHijYOEs1TeAMZblW+4Odp0Sp4 gZwO
M8z61S0zOEsYAmrEHR3gvUxWec/7WA==
=TnmP
-----END PGP SIGNATURE-----

--
Re: More regular point releases schedule? [message #2800 is a reply to message #2798] Wed, 06 February 2019 16:58 Go to previous messageGo to next message
Holger Levsen
Messages: 15
Registered: October 2018
Karma: 0
Junior Member
On Wed, Feb 06, 2019 at 05:54:29PM +0100, Marek Marczykowski-Górecki wrote:
> It may be a good idea to introduce regular schedule for stable [point
> releases[1]. It would minimize the need to download a lot of updates
> just after installation. This is even more significant, if some updates
> may require non-standard update procedure (like installing new template
> versions). Such releases should also be coordinated with relevant
> templates maintainers.

good idea!

> I'm not sure what such schedule should look like, every 3 months? 6 months?

start slow, with 6 months, and increase the frequence if deemed useful?


--
tschau,
Holger

------------------------------------------------------------ -------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

--
Re: More regular point releases schedule? [message #2809 is a reply to message #2798] Wed, 06 February 2019 19:10 Go to previous messageGo to next message
Foppe de Haan
Messages: 18
Registered: October 2018
Karma: 0
Junior Member
On Wednesday, February 6, 2019 at 5:54:37 PM UTC+1, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> It may be a good idea to introduce regular schedule for stable [point
> releases[1]. It would minimize the need to download a lot of updates
> just after installation. This is even more significant, if some updates
> may require non-standard update procedure (like installing new template
> versions). Such releases should also be coordinated with relevant
> templates maintainers.
>
> I'm not sure what such schedule should look like, every 3 months? 6 months?
>
Going by the amount of issues on the updates-status github page, I'd say once every 4 or 6mo would be ample. Could also commit to 2 or 3 per year depending on big changes / additions, but that will probably involve more stress/overhead than simply having it be part of a release schedule.

--
Re: More regular point releases schedule? [message #2811 is a reply to message #2798] Wed, 06 February 2019 19:25 Go to previous messageGo to next message
Chris Laprise
Messages: 111
Registered: October 2018
Karma: 0
Senior Member
On 2/6/19 11:54 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> It may be a good idea to introduce regular schedule for stable [point
> releases[1]. It would minimize the need to download a lot of updates
> just after installation. This is even more significant, if some updates
> may require non-standard update procedure (like installing new template
> versions). Such releases should also be coordinated with relevant
> templates maintainers.
>
> I'm not sure what such schedule should look like, every 3 months? 6 months?
>
> Any opinions?
>
> [1] https://www.qubes-os.org/doc/version-scheme/#release-version .

Using a factor other than feature sets (like time) as the determinant is
a problem. The reason is that it makes it harder for tools/apps to
target Qubes according to the version number.

If you really want to do this schedule, I recommend using a sub-point
increment (just as for bug fixes) but with a date indicator also present
in all the relevant release and package files.

--

Chris Laprise, tasketatposteodotnet
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
Re: More regular point releases schedule? [message #2814 is a reply to message #2798] Wed, 06 February 2019 19:50 Go to previous messageGo to next message
Zrubi
Messages: 60
Registered: October 2018
Karma: 0
Member
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/6/19 5:54 PM, Marek Marczykowski-Górecki wrote:

> I'm not sure what such schedule should look like, every 3 months?
> 6 months?

I would synchronize this with the most used guest templates: the
Fedora and the Debian releases. Means it should not be purely time
based: see the latest debian point release.

Of course the future Xen bugs may also require a new iso.

If it is only time based, it may be happen that you release a new
Qubes iso, and in the next days debian/fedora/Xen may release a new
version. which makes the qubes release obsoleted.


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

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxbOnQACgkQVjGl enYH
FQ0P2Q/+NV7h4CnXV0/9gYU4tVNuE8d0aqSu68APxSJ1j7/1308F7WKaWBd9 dvAx
gNoLi3PNBXuXUrCOleGfPF479Mzblz2sadjtzRLJ2qU70c+Zta1JX/5fw3AC ADg4
y1WbTgr+qOFVgVOg+oLlaOL6elO6Wr+mdF8XhXzZQduIua3HjVmDDWQEQfgd egRc
KT9Y/VFhD+AW7BmDqPVQ47O3X0VphiEr+myszMIyBNaBBCRmDsKsJVBMGOSO wLcx
yjvjm/Wp7THaNxtz7bfMvlbekrG+r7G2CRyKpnmw6pjSlzcwwBY+e3pEWwen LCUW
uJbNg/v37qTyr/lFvksm07EbyQEg1Iumf9vx50NnPsoF7WH74BnRJVKR+4ou vpXz
asajwa+VH4iGBc3vudYEWSpiCltVpmsD2+mNI3hX3MdkNZDjWGMBFU64Cc7H ChU4
8IILSv/cIWdnGo0DQqmAHV/QUXTDhNgaJ0229OkJGvocuR2ODDWzpopkbFFJ WtZk
sHsFcvMJ6fUgd8STcMtAqa/4ieZGnLX3JVV8MWIyJT1CE8QRCQJS+IkB0fs5 kP5O
YWt4nni6BA2llDuDVRJfLbWtd0VlAaDo6fCiwlbDaHPtIhu8Hfc8L/SpmSsb mCrf
JuqAxQDgiZLP8eOaly3EApejxiBeRzrkM2YDIMA+pgIkuT9yiIc=
=iCQo
-----END PGP SIGNATURE-----

--
Re: More regular point releases schedule? [message #2815 is a reply to message #2814] Wed, 06 February 2019 19:54 Go to previous messageGo to next message
Marek Marczykowski-Go
Messages: 92
Registered: October 2018
Karma: 0
Member
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Feb 06, 2019 at 08:50:19PM +0100, Zrubi wrote:
> On 2/6/19 5:54 PM, Marek Marczykowski-Górecki wrote:
>
>> I'm not sure what such schedule should look like, every 3 months?
>> 6 months?
>
> I would synchronize this with the most used guest templates: the
> Fedora and the Debian releases. Means it should not be purely time
> based: see the latest debian point release.
>
> Of course the future Xen bugs may also require a new iso.
>
> If it is only time based, it may be happen that you release a new
> Qubes iso, and in the next days debian/fedora/Xen may release a new
> version. which makes the qubes release obsoleted.

That's a good point!
So, maybe something like few weeks after new major template version
lands in stable repository? Which in most cases means every 6 months,
because of Fedora release cycle.

- --
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/THMrX1ywFAlxbO3IACgkQ24/T HMrX
1ywsPwf/TqGai5nqTxOS2jL5gvzQufAZ5ygMP8p43JpYs43jlCSwb+QqUdLE sTif
sIXxFMxjiXnV5z9HGLN4PxcGDktyedrxSBHDWepK/8f9ngAt8bzNtrk4cBJa W/D9
hobsEU3ohOb3lDkJEi6Gl+1NPpkox+kSWFAAx9pnCMJwtDecmacYXsaR5EkH HiSV
CsIZPLjqspALnX59Ly65H0z/aVc2Goz9xpFNEjmvuy0lb0cRfooSTgJx0r2x ZTx3
o83pC4pHslRSoEqUFi/kbxdqZDEkEmwJM4jh44qja7PzEYGaNPuaO9iwuGeK xCre
zWMmbSY4/JNRUI/XyRTbCRcqLLPzeg==
=XIhX
-----END PGP SIGNATURE-----

--
Re: More regular point releases schedule? [message #2820 is a reply to message #2815] Thu, 07 February 2019 02:53 Go to previous messageGo to next message
Andrew David Wong
Messages: 79
Registered: October 2018
Karma: 0
Member
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/02/2019 1.54 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Feb 06, 2019 at 08:50:19PM +0100, Zrubi wrote:
>> On 2/6/19 5:54 PM, Marek Marczykowski-Górecki wrote:
>
>>> I'm not sure what such schedule should look like, every 3
>>> months? 6 months?
>
>> I would synchronize this with the most used guest templates: the
>> Fedora and the Debian releases. Means it should not be purely
>> time based: see the latest debian point release.
>
>> Of course the future Xen bugs may also require a new iso.
>
>> If it is only time based, it may be happen that you release a
>> new Qubes iso, and in the next days debian/fedora/Xen may release
>> a new version. which makes the qubes release obsoleted.
>
> That's a good point! So, maybe something like few weeks after new
> major template version lands in stable repository? Which in most
> cases means every 6 months, because of Fedora release cycle.
>

This sounds good to me.

I agree that having more frequent point releases is a good idea, since
it makes it easier for new users to get started with Qubes and makes
it easier for existing users to upgrade. However, as others have
pointed out, this benefit doesn't require *rapid* point releases, and
there is little to be gained by trying to stick to a rigid schedule.
Event-driven at roughly six-month intervals sounds fine.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

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

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxbnbIACgkQ203T vDlQ
MDAPcRAAsY8MFH9Nw0GB0rWMmE6WfQOBAoAhWd1cpocS1Mbmu5ZPS2UE2JSB nJ+4
2HC/8zPNKBrc2fiUEk1qiyJ20PT3MoCDu86ld0Njrt7aIQyJG2CBl06qN9Fp 5dfp
gVeFGJ06mdss9VwxETZIFV9tWw6KN+XK9gnh2LHCl85ikJZdeTtAlbBjBxmA io5b
iKbxRlAupQtApP6WbHS9E85C181S3KtAPqRKvyi2+Twcj3k62H23qTGWIHiK wuHd
0lvDIEGRnakiHMEBGOZJM1iu+uNE8i2P7DrLtqNyHtnlGByEGo0W29tr4mFp JTq/
ObASIC8ZtUcjgaaghZvjIWk3Lt0PfrQ3nV1mBbkmp0D5D96LgbZhxXglzA5q fobw
e2SwCHatfnSIjYMp2CZo+K8k2xCnlqWLYscdpHl1Sp0UXqpvwVcnI91E4sSt Bc6J
8YrCFA0Erfw5UlDF0568ElnYdVZhNUDx39n0huAuNafYbXJX8rQhBLt2fonu w1AY
ddbsVi0ZK+vPDoks/Zkxr/4ytKBpJ/6bh4NgQvrxJWwhnjBWnK+Dsq+Q1uz2 9Czc
72QM7B0id89/xc8lbdOdjDyZqA7i3nzVD5XQl76S2qHNCC318pI/AF+SkddY wHOw
Wl6AzvRePVGbCiIEP6WRLAe0eQ9+1xEQnhxum12S9c5XS3zOTZc=
=Q0gq
-----END PGP SIGNATURE-----


--
Re: More regular point releases schedule? [message #2848 is a reply to message #2798] Fri, 08 February 2019 09:28 Go to previous messageGo to next message
Patrick Schleizer
Messages: 29
Registered: October 2018
Karma: 0
Junior Member
From the Whonix side that should work quite well. Perhaps worthwhile to
automate testing after the build process somehow for some basics?

whonixcheck --verbose --leak-tests

Worthwhile to run in inside all Whonix VMs (gateway+workstation
template, anon-whonix, sys-whonix, dvm-template, and DispVM).

whonixcheck exit codes should be reliable already (or easily be fixed by
me to be made reliable). Only exception:

The "systemd-modules-load.service loaded failed failed Load Kernel
Modules" bug [1] currently results in a non-zero exit code. So I'd
either would have to relax that test or wait for that Qubes bug to be
fixed. Or manually read the output of whonixcheck.

Other prudent tests:
Check if torbrowser starts from anon-whonix and DispVM. I could add test
to "whonixcheck --test" which checks that Tor Browser indeed ended up in
user home folder and has expected hardcoded version number to automate
that as well if deemed useful.

("--test" or so meaning "for use in automated testing after template build")

Should be quite stable but not a good idea to release entirely untested
templates.

Cheers,
Patrick

[1] It's either
https://github.com/QubesOS/qubes-issues/issues/4608
and/or
https://github.com/QubesOS/qubes-issues/issues/2638

--
Re: More regular point releases schedule? [message #2854 is a reply to message #2848] Fri, 08 February 2019 11:19 Go to previous messageGo to next message
Marek Marczykowski-Go
Messages: 92
Registered: October 2018
Karma: 0
Member
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Feb 08, 2019 at 09:28:00AM +0000, Patrick Schleizer wrote:
> From the Whonix side that should work quite well. Perhaps worthwhile to
> automate testing after the build process somehow for some basics?
>
> whonixcheck --verbose --leak-tests
>
> Worthwhile to run in inside all Whonix VMs (gateway+workstation
> template, anon-whonix, sys-whonix, dvm-template, and DispVM).

That's a good idea. I'll add it to other qubes tests.

BTW we finally achieved the case when all integration tests succeeded in
the same test run:
https://openqa.qubes-os.org/tests/overview?distri=qubesos&am p;version=4.0&build=4.0-20190126-1&groupid=6
Even though Qubes is running inside KVM there.
This means interpreting results is much easier now. It isn't 100% stable
yet, but it is a major progress anyway.

> whonixcheck exit codes should be reliable already (or easily be fixed by
> me to be made reliable). Only exception:
>
> The "systemd-modules-load.service loaded failed failed Load Kernel
> Modules" bug [1] currently results in a non-zero exit code. So I'd
> either would have to relax that test or wait for that Qubes bug to be
> fixed. Or manually read the output of whonixcheck.
>
> Other prudent tests:
> Check if torbrowser starts from anon-whonix and DispVM. I could add test
> to "whonixcheck --test" which checks that Tor Browser indeed ended up in
> user home folder and has expected hardcoded version number to automate
> that as well if deemed useful.
>
> ("--test" or so meaning "for use in automated testing after template build")

Does it mean "whonixcheck --test" should be run in addition to
"whonixcheck --verbose --leak-tests"? Or one contain the other?

> Should be quite stable but not a good idea to release entirely untested
> templates.
>
> Cheers,
> Patrick
>
> [1] It's either
> https://github.com/QubesOS/qubes-issues/issues/4608
> and/or
> https://github.com/QubesOS/qubes-issues/issues/2638

- --
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/THMrX1ywFAlxdZa8ACgkQ24/T HMrX
1yzOqQf6Axdc3qX7AFfaiSkNZSydpKBMo9gd8t6ZryfWBf/R/+sPpYemkDsu kTbg
yXEaakpHK3rbUlFXgv/6sk0g9RcN2tfvcCtB5EFxHi9GOb0soRgKFedzq4Yb huEU
5XYvymI6dQqmOlFO7rYUhBzr+Gur3PWGkU/Lfr6Iqqp204xfVwg5ERlwsc/C /MZ0
jrVHUMt285BXOPjMN7Cs5d5fjZx5bNOog6CianrHoE0d2dt6EO2R58cHSaqq h6lU
TZeufrFaYbfE6I3nzBymUkk8vogcFs7D2KcniARVS2jAx1W97qcEzDrxMnqs h2SO
fLmxf47c1LxDBC/t7KWvJse1iAZsHA==
=RWku
-----END PGP SIGNATURE-----

--
Re: More regular point releases schedule? [message #3201 is a reply to message #2854] Sat, 16 February 2019 16:12 Go to previous message
Patrick Schleizer
Messages: 29
Registered: October 2018
Karma: 0
Junior Member
Marek Marczykowski-Górecki:>> Other prudent tests:
>> Check if torbrowser starts from anon-whonix and DispVM. I could add test
>> to "whonixcheck --test" which checks that Tor Browser indeed ended up in
>> user home folder and has expected hardcoded version number to automate
>> that as well if deemed useful.
>
>> ("--test" or so meaning "for use in automated testing after template build")
>
> Does it mean "whonixcheck --test" should be run in addition to
> "whonixcheck --verbose --leak-tests"? Or one contain the other?

That's up for consideration. Both ways are ok.

I guess an additional --test would be fine.

Note: --test does not exist yet.

Meanwhile "whonixcheck --verbose --leak-tests" will be a good start.

Cheers,
Patrick

--
Previous Topic: Unable to port forward
Next Topic: What's the point of qvm-pool?
Goto Forum:
  


Current Time: Mon Feb 18 00:25:06 UTC 2019