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