[PureOS] Let's stablize PureoS Green
Nicole Faerber
nicole.faerber at puri.sm
Wed Mar 20 09:50:50 PDT 2019
On Wed, 2019-03-20 at 14:10 +0100, Tobias Bernard wrote:
> To add my perspective:
> I fully agree with Francois' vision. What we need long-term is
> - a user-facing OS that is stable, but which receives timely updates
> to UX-relevant parts of the stack (primarily GNOME and its
> dependencies, but probably also popular browsers, and a few other
> apps and developer tools). We don't want to split our OS in two for
> enterprise/consumer, as it would have very problematic effects on the
> developer ecosystem and the cohesion of the platform (e.g. apps
> designed for the fresher consumer version might not work on the
> enterprise one).
> - a way to do integration testing with in-development parts of the
> stack (primarily GNOME and things we need for the phone). Ideally,
> this would always have nightly versions of the entire GNOME platform
> throughout the development cycle. Most likely we'd need to do this in
> close collaboration with some GNOME people.
> - great flatpak integration for third-party apps (to alleviate the
> need to have the latest version of every random app packged) and the
> PureOS Store
> What we need to do to get there is a different question :)
>
> Regarding the current choice between Debian stable and testing: We
> can't go with Debian stable, unless we find a way to get up-to-date
> versions of GNOME and all its dependecies on top of that. I have a
> hunch that this isn't easily possible, but it's hardly my area of
> expertise :)
> Continuing with Debian testing seems like the more sustainable route
> short-term, though we still need to figure out how to get up-to-date
> GNOME during freeze periods, such as the current one. Since other
> Debian-based distributions, such as Ubuntu are going to do this as
> well, it seems at least theoretically doable.
> Longer-term I'd be interested in exploring alternative options, such
> as rebasing the OS on Endless OS, Ubuntu, or Fedora Silverblue, all
> of which have different, potentially interesting solutions to this
> problem. Sooner or later we'll want to go in a fully containerized
> direction a la Silverblue, so this might be good to factor into the
> decision we take now.
At least concerning this longer term approach I have a very strong
opinion against it. Even if these provide solutions to problems we also
face on a technical level, all of them (Endless OS, Ubuntu, or Fedora
Silverblue) are more or less dependent on a company in their backyard.
But we want to be and stay independent. That's why we chose Debian and
one of the reasons why we chose GNOME over KDE/Qt (Qt is run by a
company).
So even if there would be technical reasons, I would rather like to
invest in Debian to solve them than in using a solution backed by a
foreign company. We can look at them and use them as example or guide,
but I do not see us rebasing PueOS on anyone of these.
> Cheers,
> Tobias
Cheers
nicole
> On 3/20/19 12:47 PM, Jonas Smedegaard wrote:
> > Quoting François Téchené (2019-03-20 12:09:38)
> > > On 19/03/2019 20:50, Jonas Smedegaard wrote:
> > > > Ok, so "our users" is one target, not several.
> > > >
> > > > Not "enterprise customers" needing particularly stable system
> > > > and
> > > > "existing users" expecting a constant flow of updates from
> > > > Debian
> > > > testing.
> > > >
> > > > All users are in same boat, and the boat goes in the direction
> > > > that
> > > > the majority need to go.
> > > >
> > > > Makes good sense.
> > > >
> > >
> > > Exactly, I think that in term of expectation, both enterprise and
> > > everyday customers will expect a system that is stable, easily
> > > usable
> > > and feature full.
> > >
> > > Stability and usability are stronger in that expectation so we
> > > shouldn't target users looking for cutting edge features that
> > > are
> > > breaking stability and usability on the default experience.
> > >
> > > So in term of priority regarding the customers experience, we
> > > have the
> > > following :
> > >
> > > 1 - Stability
> > > 2 - Usability
> > > 3 - Features
> >
> > Let me provoke you...
> >
> > So until the feature and usability improvements are stable
> > integrated
> > with the system, we should provide our users a system _without_
> > those
> > improvements?
> >
> > I translate that to basing PureOS on Debian stable, not Debian
> > testing,
> > even if that means missing out on GNOME 3.32 and libhandy.
> >
> > (except on the phone where Debian stable is "too stable" i.e.
> > broken).
> >
> >
> > > The fact of improving GNOME is directly related to usability in
> > > the sens
> > > that we want to create a consistent (convergent) experience
> > > across the
> > > different Librem devices along with a tight integration with the
> > > Librem
> > > services.
> > >
> > >
> > > > What we can do now, with our current manpower and
> > > > infrastructure, is
> > > > follow Debian closely - which means a general feature update of
> > > > our
> > > > system not every 6-12 months, but either every day or every 2-
> > > > 4
> > > > years.
> > > >
> > > > We can develop different/smarter infrastructure and later when
> > > > that
> > > > is done we can choose a 3rd path similar to Ubuntu, of a 6-12
> > > > month
> > > > release cycle meaning that we deviate further from Debian at
> > > > times.
> > > > Later, not now, with our current infrastructure. If we want
> > > > such
> > > > 3rd path.
> > > >
> > > > And/or we can hire more people to help maintain PureOS, and
> > > > later
> > > > when they are settled in and efficient with our infrastructure,
> > > > we
> > > > can deviate further from Debian even before we have
> > > > different/smarter infrastructure in place, by pouring more man
> > > > hours
> > > > into the things now covered mostly by Debian - including
> > > > security
> > > > tracking and regression testing and bootstrapping new packages
> > > > and
> > > > translating and and and... If we want to deviate more from
> > > > Debian.
> > > >
> > > > For now we can choose between 2 Debian tracks: Stable or
> > > > Testing.
> > > >
> > > >
> > >
> > > What we need, in my opinion, is a stable core OS where we control
> > > the
> > > release cycles of the projects we develop and contribute to
> > > (currently
> > > GNOME)
> > >
> > > It may not be doable with the current man power but I imagine
> > > the
> > > following workflow :
> > >
> > > - PureOS "red" matching Debian Experimental (or Sid?) would let
> > > the
> > > devs work on new GNOME features.
> > >
> > > - PureOS "orange" matching Debian Stable with an exception for
> > > the
> > > GNOME packages being updated from PureOS "red" every official
> > > GNOME
> > > releases (starting from RC releases), would let the design team
> > > and
> > > other testers test the latest GNOME in the real (stable) world.
> > >
> > > - PureOS "green" being a snapshot of PureOS "orange" every time
> > > PureOS "orange" is defined as stable would be the official
> > > PureOS
> > > release for the people.
> > >
> > > This is just a proposal that may not reflect the reality of
> > > technical
> > > issues but it is mainly to illustrate the fact that we keep
> > > control of
> > > the testing and stability of what we develop.
> >
> > Makes good sense to _develop_ such separation between "core OS"
> > and
> > other parts.
> >
> > It is not possible to make such distinction _today_ however: Even
> > if our
> > manpower is sufficient today, we can only _today_ choose between
> > Debian
> > options. We have no other options to choose from _today_.
> >
> > As an example, use of flatpak for other parts is an option _later_
> > when
> > we have gained experience with how it can sustainably and reliably
> > integrate with whatever subset of Debian we decide is "core".
> >
> >
> > > > > I think this is a critical time for us in term of user
> > > > > experience
> > > > > so we must not rush in the decisions and make sure we find a
> > > > > good
> > > > > compromise.
> > > >
> > > > Reason it is kinda urgent to reflect on this now is that _if_
> > > > we
> > > > decide to hit the break and slow down to tracking Debian
> > > > stable,
> > > > then we cannot take that decision at arbitrary points during
> > > > the
> > > > Debian development cycle: We need to decide before Debian
> > > > releases
> > > > the next stable release, likely within few months from now, or
> > > > continue fast-paced tracking Debian testing until the next
> > > > window
> > > > 2-4 years from now.
> > > >
> > >
> > > OK, I understand Jonas. It is the right time to discuss that
> > > issue and
> > > I am sure we will find a good solution for the short and longer
> > > term!
> >
> > We can discuss both what to do now, and what to invest resources
> > in
> > developing for a potential (if research is fruitful!) near future.
> >
> > We can discuss those related but different topics together IF we
> > make it
> > VERY clear at all time which part we are talking about when.
> >
> >
> > - Jonas
> >
> >
> >
> > _______________________________________________
> > Pureos-project mailing list
> > Pureos-project at lists.puri.sm
> > https://lists.puri.sm/listinfo/pureos-project
>
> _______________________________________________
> Pureos-project mailing list
> Pureos-project at lists.puri.sm
> https://lists.puri.sm/listinfo/pureos-project
--
Purism SPC
https://puri.sm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190320/1bae70ea/attachment-0001.sig>
More information about the Pureos-project
mailing list