Hi,
In the few months I've been with Purism, I've been astonished by the ability of the team to build PureOS with the resources at hand. One of the reasons for this is likely the use of Laniakea as CI but of course the bulk of the reason is the quality of the base distro and the experience of those who're developing PureOS.
There are naturally some pain points that come with new products like the Purism Librem laptops. I think that some of these rough edges might be smoothed by following Debian Testing as it becomes Debian Stable and keeping Debian Stable as our "Green" repository for PureOS packages.
I've floated this idea internally in Purism and there has been a great deal of support for the idea. Others have also identified Debian Testing as being too fast moving for the Librem. While I mentioned this in another thread, I'd like to use this thread for discussion on the idea's merits as well as what is required technically to do this.
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Thanks,
Jeremiah
Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Above is strongly tied the related question of what to do about cravings for exciting new $stuff as Buster (non-)evolves to become steadily more boring over its multi-year lifespan.
Do we...
a) Tell users to wait for it to become boring enough? b) Maintain a local fork as .deb in PureOS for each wish? c) Maintain a local flatpak for each wish? d) Tell users to include .deb/flatpack maintained elsewhere?
With a) I say yes let's do it. But I expect others in the company to not really want that option for several years, not even for enterprise users. Testing that is simple: Imagine PureOS being Stretch until 6 months from now (i.e. until Buster becomes boring _and_ we finish testing that it really truly is boring also with our adaptations).
With b) I say no: We lack manpower, procedures, and infrastructure to handle that - including security tracking but also other things.
With c) I say that those responsible for flatpack maintenance need to evaluate when they are ready - including security tracking but also other things. Which implies that it is a no if PureOS team has that responsibility.
With d) I say no: It is irresponsible of us to point our users elsewhere.
- Jonas
On 3/14/19 1:52 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Above is strongly tied the related question of what to do about cravings for exciting new $stuff as Buster (non-)evolves to become steadily more boring over its multi-year lifespan.
I might give you another perspective from an intermediate user. What some of you 'OS nerds' ;) consider boring, I'm guessing the majority of our customers see it as a very functional, cool as-is tool to get things done. As long as privacy and security improvements don't get stagnant... And any customer that may be as advanced as you guys, will know the ways to make it un-boring :)
Do we...
a) Tell users to wait for it to become boring enough? b) Maintain a local fork as .deb in PureOS for each wish? c) Maintain a local flatpak for each wish? d) Tell users to include .deb/flatpack maintained elsewhere?
With a) I say yes let's do it. But I expect others in the company to not really want that option for several years, not even for enterprise users. Testing that is simple: Imagine PureOS being Stretch until 6 months from now (i.e. until Buster becomes boring _and_ we finish testing that it really truly is boring also with our adaptations).
With b) I say no: We lack manpower, procedures, and infrastructure to handle that - including security tracking but also other things.
With c) I say that those responsible for flatpack maintenance need to evaluate when they are ready - including security tracking but also other things. Which implies that it is a no if PureOS team has that responsibility.
With d) I say no: It is irresponsible of us to point our users elsewhere.
- Jonas
- Omar
Pureos-project mailing list Pureos-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
On Thu, 2019-03-14 at 15:10 -0500, Omar wrote:
On 3/14/19 1:52 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Above is strongly tied the related question of what to do about cravings for exciting new $stuff as Buster (non-)evolves to become steadily more boring over its multi-year lifespan.
I might give you another perspective from an intermediate user. What some of you 'OS nerds' ;) consider boring, I'm guessing the majority of our customers see it as a very functional, cool as-is tool to get things done. As long as privacy and security improvements don't get stagnant... And any customer that may be as advanced as you guys, will know the ways to make it un-boring :)
+1
I think the majority of our enterprise user base will feel the exact same way.
Do we...
a) Tell users to wait for it to become boring enough?
Yes.
b) Maintain a local fork as .deb in PureOS for each wish? c) Maintain a local flatpak for each wish?
flatpak is going to be installed on the system so those who want cutting edge can turn to that.
d) Tell users to include .deb/flatpack maintained elsewhere?
With a) I say yes let's do it. But I expect others in the company to not really want that option for several years, not even for enterprise users.
What evidence supports this? I've generally received positive feedback when talking about stability with the move to Debian Stable from other parts of PureOS. I have received some anecdotal evidence along the lines you've stated, that 5 years is too long, but two years may be reasonable. H
What about providing a dist-upgrade to Bullseye when it is stable?
Testing that is simple: Imagine PureOS being Stretch until 6 months from now (i.e. until Buster becomes boring _and_ we finish testing that it really truly is boring also with our adaptations).
With b) I say no: We lack manpower, procedures, and infrastructure to handle that - including security tracking but also other things.
With c) I say that those responsible for flatpack maintenance need to evaluate when they are ready - including security tracking but also other things. Which implies that it is a no if PureOS team has that responsibility.
With d) I say no: It is irresponsible of us to point our users elsewhere.
I think your points here are all valid and ought to be kept in mind.
Regards,
jeremiah
Quoting Jeremiah C. Foster (2019-03-14 21:29:01)
On Thu, 2019-03-14 at 15:10 -0500, Omar wrote:
On 3/14/19 1:52 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Above is strongly tied the related question of what to do about cravings for exciting new $stuff as Buster (non-)evolves to become steadily more boring over its multi-year lifespan.
I might give you another perspective from an intermediate user. What some of you 'OS nerds' ;) consider boring, I'm guessing the majority of our customers see it as a very functional, cool as-is tool to get things done. As long as privacy and security improvements don't get stagnant... And any customer that may be as advanced as you guys, will know the ways to make it un-boring :)
+1
I think the majority of our enterprise user base will feel the exact same way.
Ok, so the majority of users would be happy today with...
* Linux 4.9 * GNOME 3.22 * LibreOffice 5.2
Great!
I am not grumpy about that at all. I thought I heard others in Purism - people _not_ in PureOS team - be grumpy about especially GNOME not being new and shiny - but possibly I misunderstood or our real users are far different and easier to satisfy. Just great :-)
Do we...
a) Tell users to wait for it to become boring enough?
Yes.
Great! I am happy to be mistaken.
b) Maintain a local fork as .deb in PureOS for each wish? c) Maintain a local flatpak for each wish?
flatpak is going to be installed on the system so those who want cutting edge can turn to that.
Do you confirm that we _will_ hire enough people to handle locally maintained flatpaks?
d) Tell users to include .deb/flatpack maintained elsewhere?
...or did you mean that we rely on externally maintained flatpaks?
With a) I say yes let's do it. But I expect others in the company to not really want that option for several years, not even for enterprise users.
What evidence supports this?
Evidence?!?
I have absolutely zero evidence about _any_ of the 4 scenarios: PureOS never explored any of them, so this is all pure speculation.
I've generally received positive feedback when talking about stability with the move to Debian Stable from other parts of PureOS. I have received some anecdotal evidence along the lines you've stated, that 5 years is too long, but two years may be reasonable. H
So we bet on Bullseye being stable in two years, or we switch PureOS to being a rolling release in two years, or why mention that timespan?
I cannot promise a certain timeframe, but have evidence of historical pace of Debian releases: https://timeline.debian.net/
What about providing a dist-upgrade to Bullseye when it is stable?
What about it?
As with everything else, there are the same 4 scenarios.
For scenario a) Debian supports dist-upgrade from one stable to next stable, so as long as PureOS tracks stable releases of Debian then PureOS is equally dist-upgradeable.
Any parts deviating from Debian is our headache to ensure upgradeability for, however. Currently we have practically zero testing - manual or automated - because we are currently a rolling release where upgrading is eternal: Anyone had problems last week? Just try again this week, perhaps the problem fixed itself...
But if I understand correctly, we eliminate maintenance issues, including upgradablitity, by using flatpak for anything where Debian has evidence of maintenance being required.
- Jonas
On Fri, 2019-03-15 at 00:50 +0100, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-14 21:29:01)
On Thu, 2019-03-14 at 15:10 -0500, Omar wrote:
On 3/14/19 1:52 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Above is strongly tied the related question of what to do about cravings for exciting new $stuff as Buster (non-)evolves to become steadily more boring over its multi-year lifespan.
I might give you another perspective from an intermediate user. What some of you 'OS nerds' ;) consider boring, I'm guessing the majority of our customers see it as a very functional, cool as-is tool to get things done. As long as privacy and security improvements don't get stagnant... And any customer that may be as advanced as you guys, will know the ways to make it un-boring :)
+1
I think the majority of our enterprise user base will feel the exact same way.
Ok, so the majority of users would be happy today with...
- Linux 4.9
I think any LTS kernel is fine as long as it has the right features we need. I'll check with Mr. Chromebox and Kyle to see if there are specific kernel versions needed for Pureboot and friends.
- GNOME 3.22
I know there are those among us who won't use anything less than the latest GNOME. I'm sorry to disappoint but I don't see any way we can provide bleeding edge GNOME to our user base aside from side loading via flatpak (which is what GNOME itself seems to be moving towards.)
- LibreOffice 5.2
Here we need to hear from the Enterprise Sales team to see what they feel. I imagine that functionality is crucial as is interoperability with standard document formats to the greatest degree possible. I think many may be happy without the latest bells and whistles.
Great!
+1
I am not grumpy about that at all. I thought I heard others in Purism - people _not_ in PureOS team - be grumpy about especially GNOME not being new and shiny - but possibly I misunderstood or our real users are far different and easier to satisfy. Just great :-)
:-) I think that we can provide a solid GNU/Linux distro that is tailored to secure hardware. That is going to be a real win for our user base I believe and for the laptop market in general.
Cheers,
Jeremiah
Hi, On Thu, Mar 14, 2019 at 03:10:05PM -0500, Omar wrote:
On 3/14/19 1:52 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
Above is strongly tied the related question of what to do about cravings for exciting new $stuff as Buster (non-)evolves to become steadily more boring over its multi-year lifespan.
I might give you another perspective from an intermediate user. What some of you 'OS nerds' ;) consider boring, I'm guessing the majority of our customers see it as a very functional, cool as-is tool to get things done. As long as privacy and security improvements don't get stagnant... And any customer that may be as advanced as you guys, will know the ways to make it un-boring :)
Do we...
a) Tell users to wait for it to become boring enough? b) Maintain a local fork as .deb in PureOS for each wish? c) Maintain a local flatpak for each wish? d) Tell users to include .deb/flatpack maintained elsewhere?
With a) I say yes let's do it. But I expect others in the company to not really want that option for several years, not even for enterprise users. Testing that is simple: Imagine PureOS being Stretch until 6 months from now (i.e. until Buster becomes boring _and_ we finish testing that it really truly is boring also with our adaptations).
With b) I say no: We lack manpower, procedures, and infrastructure to handle that - including security tracking but also other things.
Currently I doubt we'll be able to maintain just one baseline. So having a color track stable and another one testing (snapshots) makes sense to me. Yes this needs people and infrastructure but I don't think purism will scale out otherwise.
With c) I say that those responsible for flatpack maintenance need to evaluate when they are ready - including security tracking but also other things. Which implies that it is a no if PureOS team has that responsibility.
Flatpak doesn't handle things like updated drivers, system daemons etc so this will only work for a subset of problems at hand. In my simplistic world view flatpak solves the 'updated app" problem to some extend (which is a hard one by itself) but it doesn't help you with baseline updates - so it's rather on top of all the other alternatives.
Cheers, -- Guido
With d) I say no: It is irresponsible of us to point our users elsewhere.
- Jonas
- Omar
Pureos-project mailing list [1]Pureos-project@lists.puri.sm [2]https://lists.puri.sm/listinfo/pureos-project
References
Visible links
- mailto:Pureos-project@lists.puri.sm
- https://lists.puri.sm/listinfo/pureos-project
Pureos-project mailing list Pureos-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
Hi, On Thu, Mar 14, 2019 at 01:57:44PM -0400, Jeremiah C. Foster wrote: [..snip..]
I've floated this idea internally in Purism and there has been a great deal of support for the idea. Others have also identified Debian Testing as being too fast moving for the Librem. While I mentioned this in another thread, I'd like to use this thread for discussion on the idea's merits as well as what is required technically to do this.
On the Librem 5 side there's three things:
* The need for a solid distribution (this does not necessarily mean Debian stable, it could e.g. also be based on Debian testing snapshots which we stabilize) including security support. It could also make sense to only look at a subset of packages instead of the whole Debian archive. * The need for newer packages than in Debian stable (e.g. updated GNOME) (on the laptop side newer x.org / kernel /mesa come to mind with newer laptop generations). * A n year/month support policy to switch between these
We need to get these things together somehow and I think this would also benefit laptop users that want longer term stability (i.e. the enterprise). It might make sense to collect the requirements of different parties somewhere (I tried so with PureOS issues).
Cheers, -- Guido
Hi!
Am Do., 14. März 2019 um 18:58 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...] There are naturally some pain points that come with new products like the Purism Librem laptops. I think that some of these rough edges might be smoothed by following Debian Testing as it becomes Debian Stable and keeping Debian Stable as our "Green" repository for PureOS packages.
I've floated this idea internally in Purism and there has been a great deal of support for the idea. Others have also identified Debian Testing as being too fast moving for the Librem. While I mentioned this in another thread, I'd like to use this thread for discussion on the idea's merits as well as what is required technically to do this.
What do those folks on this mailing list think? Should we keep PureOS Green on Debian (Buster) Stable?
First of all, I do think that if we want to have any chance in attracting "enterprise" customers to PureOS, there is no way we can offer them a (semi) rolling release distribution like PureOS currently is, so that would have to change. Either by tracking Debian stable outright, or by freezing PureOS' state at some point like Ubuntu does, or by creating a new non-rolling suite dedicated to enterprise.
I do see some issues though that we'd have to address somehow or deliberately choose to ignore as not important to us.
0) The biggest non-technical issue I see with changing the status quo is marketing. When I joined Purism, the task was explicitly to create PureOS as a rolling-release distribution based on Debian testing. The motivation back then was to give users a relatively recent desktop environment with recent applications that are continuously updated. The focus was explicitly on non-Linux-enthusiast end-users, not enterprise. And this is what users expect when installing PureOS, given that all our marketing is advertising PureOS as such. If we suddenly freeze green on stable and require users to dist-upgrade to a new version at some point, we break the marketing promise. We might choose to ignore this issue, but we should be aware of it. The issue could also be mitigated by keeping "green" on the rolling release track and creating a new suite dedicated to being based on Debian stable.
The remaining issues are more technical:
1) Distribution Upgrades We are still focused on end-users who have no technical experience, so how do users know when their current OS release will run out of support? How do we provide a sensible upgrade path between distributions that is reliable, graphical and easy to use? I just recently landed a few changes in AppStream which will make this possible at some point, but we are in no way there yet.
2) How do we track security updates? At the moment, we get security updates for free via testing automatically. If we made changes to packages in PureOS and an update can't be synced from Debian, Laniakea will warn about that. If we have a stable suite of PureOS, we will need a team to fix issues in our packages manually and quickly once we received information that there is a security issue that affects a package we changed. We could likely automate the notification procedure, the fixing and testing would have to be done by humans.
3) Should we actually freeze green? If we decide to freeze green, it means we'll break the marketing promise somewhat, but it also means that our users will suddenly need additional APT sources for green-updates and green-security packages. Which means we would need to mess with user's APT sources.list to include them at some point. Alternatively we could create a new suite that we dedicate to being stable, keeping green as semi-rolling release target. That would be a bit strange as well though, because if you want the bleeding edge stuff you can already use the "landing" suite.
4) Where and how are new features developed? For the next PureOS release, in landing, of course. So landing would be the target for the phone team and the PureOS team to break as they like until we release it as stable when the next Debian stable release drops. But what happens if we need a new feature X *now* on the laptops for some reason? Do we add it to the frozen stable suite? That seems a bit wrong. But if we only have it on the upcoming release, we will have to wait for a while for it to reach end users. For the phone team things might also get complicated. While everything is bleeding edge right now, at some point we will want a "stable-ish" phone image. Do we wait for the next Debian release to do that? Or do we branch off the current development suite for that? Or will the phone stay bleeding-edge forever?
On a more general note, if we want a frozen PureOS, there are 3 ways to achieve it:
A) Freeze PureOS green suite to track Debian buster, do green+1 development in landing This would cause us some migration trouble with existing users of green, but aside from that wouldn't require a lot of extra effort. We would need people to work on green-updates and green-security to keep bugs and security issues fixed in stable.
B) Create a new stable suite, keep green as rolling, track Debian buster in green "green" would be the rolling-release bleeding edge development version of PureOS, while we would establish a new stable channel for users to switch to. This would mean that switching to stable PureOS would be a conscious thing. However, this would mean that a lot of our users would suddenly use the now-development-target "green" suite, with increased risk for breakage as soon as we start landing experiments there (like the phone team is doing in the purple suite).
C) Mark green as stable now (tracking buster), use landing as development target and branch off new stable releases from there whenever we like This is the most flexible solution and is what Ubuntu does. This would mean we can make our own releases when it suits us, not being tied to Debian stable. This would require a significantly bigger team than we have now, as we would need to do our own security support for the branched-off releases. It would give us the greatest flexibility though, to decide which features we want to provide to users when.
In any case, it will be more work for the team :-) - but since we effectively already having four suites for PureOS ("landing" as general development target, "green" as in-use semi-rolling, "laboratory" as phone development target and "purple" as experimental phone playground comprised of "landing" and "laboratory"), this might actually make things simpler.
Cheers, Matthias
-
Guido Günther -
Jeremiah C. Foster -
Jonas Smedegaard -
Matthias Klumpp -
Omar