[PureOS] Let's stablize PureoS Green
Jonas Smedegaard
jonas.smedegaard at puri.sm
Thu Mar 14 16:50:53 PDT 2019
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
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190315/5aa420e7/attachment.sig>
More information about the Pureos-project
mailing list