[PureOS] Let's stablize PureoS Green

[Matthias Klumpp]

Hi!

Am Do., 14. März 2019 um 18:58 Uhr schrieb Jeremiah C. Foster
<jeremiah.foster at 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