Let's stablize PureoS Green
Hi, I am joining this discussion to expose the vision from the UI/UX design side of PureOS. In term of UI/UX design, we are conforming to the Ethical Design manifesto (https://2017.ind.ie/ethical-design/) . Based on that we have defined a few guidelines that we want to make sure are respected. - One of them is that we target the majority of the population in term of user experience. This means that we should think in term of "democratic" choice. The question we keep asking ourselves is : Will the defaults work best for the majority of human beings? The idea here is to avoid proposing different flavors for different tastes but to focus on defaults that targets the majority. - Another guideline we would like to be respected is that we should contribute upstream. No matter which project we want to adopt, we shouldn't put our effort in forking it but instead in joining the community in that global effort for the sake of everyone. In that regard, we are currently contributing to the GNOME project as the default PureOS DE on both the laptop and the phone. We have been working for the past year, along with the GNOME design team in designing the GNOME mobile interfaces as well as bringing convergence to the desktop (laptop) platform. This is a work in progress that is being implemented by both the Purism devs and the community. Some of that work has already been implemented as part of GNOME 3.32. My point here is that GNOME, as a whole, along with GTK+ will dramatically evolve in the next few years in order match the user experience that we are designing and developing for the Librem products. Our goal is to define a tight integration and consistent experience between Librem Laptops, Librem Phone, PureOS, Librem One and the Librem Key. We need to experience the experience that we design and that the devs are implementing, as well as delivering to the people in a not too long frequency. So if we decide to go for a stable long term release of the core OS, one solution for us would be : - To have a "dev" PureOS repository that would let us test the latest GNOME and GTK updates (along with the stable packages of the core system in order to test the stability of a release within the current core packages?) - To be able to release GNOME upgrades to our users in a not too long frequency (maximum 1 year) ideally the 6 months GNOME release cycle. 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. Thank you! -- https://puri.sm
Quoting François Téchené (2019-03-19 19:38:23)
The question we keep asking ourselves is : Will the defaults work best for the majority of human beings? The idea here is to avoid proposing different flavors for different tastes but to focus on defaults that targets the majority.
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. [details on pushing upstream snipped - we all agree on that!]
So if we decide to go for a stable long term release of the core OS, one solution for us would be : [...] - To be able to release GNOME upgrades to our users in a not too long frequency (maximum 1 year) ideally the 6 months GNOME release cycle.
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.
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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
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 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.
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! Cheers, François -- https://puri.sm
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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
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. Cheers, Tobias 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@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
Quoting Tobias Bernard (2019-03-20 14:10:18)
To add my perspective:
[ snipped nice long-term vision of both stable and timely updated ]
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 :)
Correct, that isn't possible today. Maybe possible within 6 months - but by the time we know for certain it is likely too late to hit the breaks (should we want that by then - when new new must-have usability or feature improvement may be at hand or just around the corner).
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.
So in your opinion, short term we need _less_ stability than syncing from Debian testing offers during Debian freeze. Makes (some) sense, but unfortunately outside our options: Assuming we could switch to track Debian unstable, that would also be affected by the freeze. Assuming we could switch to track Debian unstable+experimental, we would have no way to distinguish in-experimental-because-unstable-is-occupied-by-the-freeze packages from in-experimental-because-of-horrible-experiments packages. We cannot selectively track pet packages from unstable or experimental - see https://tracker.pureos.net/T724#13610 Our options short-term are therefore limited to these: * continue track testing * switch to track stable Medium-term - after developing infrastructure and/or hiring and getting up to speed more manpower - there may be more options to choose from. Now we can discuss what to actually do now , and we can discuss what to start ramping up for attempting to maybe do in future. We cannot discuss what to do now other than "nothing" or "slow down".
Since other Debian-based distributions, such as Ubuntu are going to do this as well, it seems at least theoretically doable.
Yes, given enough resources (engineering, hands, and time), anything is possible! [ snipped vision/wish about abandoning Debian ] - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Our options short-term are therefore limited to these:
* continue track testing * switch to track stable
Medium-term - after developing infrastructure and/or hiring and getting up to speed more manpower - there may be more options to choose from.
Now we can discuss what to actually do now , and we can discuss what to start ramping up for attempting to maybe do in future.
We cannot discuss what to do now other than "nothing" or "slow down".
Since neither of these gives us what we need it doesn't really matter what we do short-term, so I guess "nothing" :) Seems that the best thing to do then is to start working out the medium/long-term solution, in order to get that in place as soon as possible. That said, while we could live with not getting 3.32 on laptops for a few more months, it would be a huge problem for the phone to ship with 3.30. Guido and Adrien can probably better comment on that, but as far as I understand we will need some kind of short term solution to get at least parts of the new GNOME stack for the phone by June/July.
On 20/03/2019 16:57, Tobias Bernard wrote:
Our options short-term are therefore limited to these:
* continue track testing * switch to track stable
Medium-term - after developing infrastructure and/or hiring and getting up to speed more manpower - there may be more options to choose from.
Now we can discuss what to actually do now , and we can discuss what to start ramping up for attempting to maybe do in future.
We cannot discuss what to do now other than "nothing" or "slow down".
Since neither of these gives us what we need it doesn't really matter what we do short-term, so I guess "nothing"
Seems that the best thing to do then is to start working out the medium/long-term solution, in order to get that in place as soon as possible.
That said, while we could live with not getting 3.32 on laptops for a few more months, it would be a huge problem for the phone to ship with 3.30. Guido and Adrien can probably better comment on that, but as far as I understand we will need some kind of short term solution to get at least parts of the new GNOME stack for the phone by June/July.
I totally agree with you Tobias. Leaving it as is if there is no short term solution and planning and working on the longer term solution from now. We really need those GNOME updates because it is what we are investing most of our development effort in. François
_______________________________________________ Pureos-project mailing list Pureos-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
Quoting Tobias Bernard (2019-03-20 16:57:21)
Our options short-term are therefore limited to these:
* continue track testing * switch to track stable
Medium-term - after developing infrastructure and/or hiring and getting up to speed more manpower - there may be more options to choose from.
Now we can discuss what to actually do now , and we can discuss what to start ramping up for attempting to maybe do in future.
We cannot discuss what to do now other than "nothing" or "slow down".
Since neither of these gives us what we need it doesn't really matter what we do short-term, so I guess "nothing" :)
Seems that the best thing to do then is to start working out the medium/long-term solution, in order to get that in place as soon as possible.
That said, while we could live with not getting 3.32 on laptops for a few more months, it would be a huge problem for the phone to ship with 3.30. Guido and Adrien can probably better comment on that, but as far as I understand we will need some kind of short term solution to get at least parts of the new GNOME stack for the phone by June/July.
Short-term, Phone system is fundamentally unstable (or "lesser stable" to phrase it less scary) and therefore excempt from any choice we make about stabilizing further or not. Based on above, here's my guess at PureOS short and medium term future: Short-term (0-6 months), PureOS does *not* switch to track Debian stable but continue to track Debian testing - i.e. grinds to a halt with Debian freeze, then blasts forward when unfrozen. Short-term, PureOS for phones deviates as needed to includes features crucial for phone use (and also quite appreciated in general but trumped by stability during Debian freeze). Medium-term (6-12 months), PureOS tracking testing leads to a bumpy ride (as time just after freeze is often the most "exciting" - both with packages let but later revealed broken in interesting complex ways, and also with packages "held ransom" in unstable while conflicting changes compete to enter Debian testing. Medium-term, PureOS for phones deviates far less as they now flow into Debian testing in same pace as other feature updates. New development in the phone team will either evolve equally slow to our users as other features in e.g. GNOME, or we short-circuit and include them in PureOS without Debian as intermediary (if we can handle that - see below!). **** I think all our current manpower in PureOS team is needed to care for maintaining - i.e. no spare resources to develop towards changing course. Seems to me that all deviations for phones is currently solely handled by the phone development team, and that seems quite risky to me: The phone developers should care for _developing_ but _maintaining_ the integration of their development should be handled by the PureOS team. Seems to me that security tracking for PureOS is currently solely handled by Debian. For each of our various deviations from Debian we desparately need to either a) upstream the changes so that its security tracking is covered by Debian, or b) establish infrastructure for and maintenance of PureOS-specific security tracking. Requiring manpower. Seems to me that maintaining PureOS deviations, including security tracking, must have higher priority than developing alternatives to closely tracking Debian testing - to improve on the design team vision about PureOS being both stable _and_ at most 6 months "behind" on newest upstream usability (and feature) changes. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
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@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 -- Purism SPC https://puri.sm
Sorry for top-posting (I'll move back to inline after this little PSA) and for changing the format back to text but text and inline comments read better for those who use text based mail clients like mutt which I and others use regularly. 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.
I'd like to see if we can't discuss this with GNOME. Integration and release cadence really could be better coordinated with Debian I feel especially given that the current GNOME Foundation director is a DD, but perhaps there's work behind the scenes going on already that I don't know about.
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.
We have to go with Debian stable. Debian testing has presented too many obstacles to stability. We have an obligation to ship stable software to our customers.
I have a hunch that this isn't easily possible, but it's hardly my area of expertise :)
I think it is entirely possible to backport GNOME 3.32 and ensure flatpak works with the lastest GNOME software. In fact, on my PureOS green system I'm running what will become Debian stable with GNOME 3.32 runtime and apps via flatpak; $ lsb_release -a Distributor ID: PureOS Description: PureOS GNU/Linux 8 Release: 8 Codename: green $ flatpak update ID Arch Branch Op Remote Download 1. [✓] org.gnome.Platform x86_64 3.32 u flathub 88.8 kB / 433.8 MB 2. [✓] org.gnome.Platform.Locale x86_64 3.32 i flathub 17.0 kB / 222.6 MB 3. [✓] org.gnome.Lollypop.Locale x86_64 stable u flathub 1.0 kB / 467.9 kB 4. [✓] org.gnome.Geary.Locale x86_64 stable u flathub 1.0 kB / 4.1 MB
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,
Will flatpak work? It works for me here.
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.
1. Endless and Silverblue both use OSTree. OSTree is good, but it is *very* different from Debian's traditional model. a) Endless is designed to be used in places that have slow internet, they preload much of the OS, including content b) Endless is based on Debian with a kernel from Ubuntu, neither of those distros are certified by FSF as "free" c) Endless and SilverBlue provides the OS as a single immutable deliverable, users do not have fine control of what is on the OS d) SilverBlue is "for container-focused workflows, this variant of Fedora Workstation targets developer communities" 2. Ubuntu is built by Canonical and is ~80% based on Debian. While they fork some things (Mir) they often find that its not worth it to fork (upstart). They recompile their packages adding ubuntu to their rebuilt packages (much the way we add pureos to our pureos packages, though we have very few), and the consequence of adding the 'ubuntu' string means that they have a trademark claim on derivatives. I don't think PureOS should be subject to capricious trademark claims so I wouldn't personally recommend Ubuntu as the base for PureOS. It's possible that a deb-ostree-builder based OS with kernel, Pureboot and middleware might be a good base for a flatpak'ed Desktop like GNOME. But I've only experimented with this and it needs more research. Its unlikely that something like that would be ready by the time we need to make the decision of stable vs. testing.
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.
Perhaps you're right. This certainly is a trend (Project Atomic, SilverBlue, Endless, Clear Linux, etc.) but that is not a reason to adopt it merely because it's trendy. I like the isolation of containers but I don't like the bloated runtimes and the duplicate runtimes, that is a security nightmare. Cheers, Jeremiah
We have to go with Debian stable. Debian testing has presented too many obstacles to stability. We have an obligation to ship stable software to our customers.
I think this is the core of the problem. We need both a reasonable degree of stability and frequent updates to user-facing things, which requires fresh versions of large parts of the stack. Debian stable is moving way too slowly for that, but it sounds like there is no good alternative to it at the moment. If we're committed to Debian as our base, perhaps we should propose overhauling the release model or adding a separate stream of stable, but more frequent releases that would allow a release cadence more in line with the needs of a consumer-facing OS (i.e. major updates once or twice a year). I assume others might be interested in this as well, seeing as it's exactly what Ubuntu et al. are doing on top of Debian already.
I'd like to see if we can't discuss this with GNOME. Integration and release cadence really could be better coordinated with Debian I feel especially given that the current GNOME Foundation director is a DD,
That would be a great start :) I know that the foundation (and GNOME community more generally) would be really interested in a nightly OS developers can dogfood, so perhaps there is collaboration potential there.
but perhaps there's work behind the scenes going on already that I don't know about.
Not as far as I know, but would be good to look into that. Cheers, Tobias
On Thu, 2019-03-21 at 16:21 +0100, Tobias Bernard wrote:
We have to go with Debian stable. Debian testing has presented too many obstacles to stability. We have an obligation to ship stable software to our customers.
I think this is the core of the problem. We need both a reasonable degree of stability and frequent updates to user-facing things, which requires fresh versions of large parts of the stack.
+1
Debian stable is moving way too slowly for that, but it sounds like there is no good alternative to it at the moment.
I think that a Debian stable 'base' with flatpak on top and/or backported apps will serve us well. Already parts GNOME 3.32 has come into the 'Experimental' which means that it will hopefully make its way into Testing later. Have parts of the GNOME 3.32 desktop already in experimental shows that there is interest in Debian in having the latest GNOME. In addition, things like Geary are already flatpak'd. I'm running a 3.32 version of Geary here on PureOS Green.
If we're committed to Debian as our base, perhaps we should propose overhauling the release model or adding a separate stream of stable, but more frequent releases that would allow a release cadence more in line with the needs of a consumer-facing OS (i.e. major updates once or twice a year). I assume others might be interested in this as well, seeing as it's exactly what Ubuntu et al. are doing on top of Debian already.
I think that it's always worthwhile to look at release process and cadence. My experience tells me that releases are best when coordinated and planned. This can be really hard given the moving parts and the fact that there are a lot of upstreams we rely on (GNOME, Debian, Linux , Coreboot, etc.)
I'd like to see if we can't discuss this with GNOME. Integration and release cadence really could be better coordinated with Debian I feel especially given that the current GNOME Foundation director is a DD,
That would be a great start :)
I'll ask Sri to help us with the contacts and get some discussions going. Perhaps we can join the GNOME Foundation in an official capacity, although I assume that has already been discussed.
I know that the foundation (and GNOME community more generally) would be really interested in a nightly OS developers can dogfood, so perhaps there is collaboration potential there.
but perhaps there's work behind the scenes going on already that I don't know about.
Not as far as I know, but would be good to look into that.
+1 Regards, jeremiah
Quoting Jeremiah C. Foster (2019-03-21 16:55:52)
I think that a Debian stable 'base' with flatpak on top and/or backported apps will serve us well.
I think the flatpak part of such plan can be ready for our users no sooner than 6-12 months if we start invest seriously in developing maintenance for it now!
Already parts GNOME 3.32 has come into the 'Experimental' which means that it will hopefully make its way into Testing later.
Making its way into testing is relevant only when tracking Debian testing. If tracking Debian stable instead, what is relevant is packages that has not only entered Debian testing but also has been backported to Debian stable. Core GNOME parts have not been backported to stable - at least not in the semi-official https://backports.debian.org/ repository, as indicated by e.g. https://packages.debian.org/gnome-session (compare with e.g. https://packages.debian.org/openvpn noticing backport-* entries).
Have parts of the GNOME 3.32 desktop already in experimental shows that there is interest in Debian in having the latest GNOME.
GNOME 3.32 in experimental does not in itself tell if Debian has a _general_ interest in having latest GNOME or that is just a one-off effort. A better indicator is looking at the flow into testing of sample GNOME parts, e.g https://tracker.debian.org/pkg/gnome-session/news/ - and then compare those dates to GNOME release dates to get the timeliness of releases entering Debian testing.
In addition, things like Geary are already flatpak'd. I'm running a 3.32 version of Geary here on PureOS Green.
Question with flatpak is not if possible to execute installed programs. but how we handle QA aspects we then no longer get from Debian - licensing and security fixes and more, for all parts also all linked in libraries and included media files etc., and when we have matured our handling to a level we dare declare stable towards our users. What is not yet stable in Debian testing is the system as a whole. Packages should be in usable form already when uploaded to unstable! If we choose to use Debian stable for some parts and flatpak and/or backports and/or home-maintained packages for some parts, then depending on how well we _MAINTAIN_ that whole construct we may end up fooling ourselves into having an expensive to maintain burden which is (different but) no better than Debian testing. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On Thu, 2019-03-21 at 18:34 +0100, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-21 16:55:52)
I think that a Debian stable 'base' with flatpak on top and/or backported apps will serve us well.
I think the flatpak part of such plan can be ready for our users no sooner than 6-12 months if we start invest seriously in developing maintenance for it now!
What needs to be done in your estimation Jonas? I run PureOS green and have a GNOME 3.32 runtime right now. Regards, Jeremiah
Quoting Jeremiah C. Foster (2019-03-22 13:51:46)
On Thu, 2019-03-21 at 18:34 +0100, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-03-21 16:55:52)
I think that a Debian stable 'base' with flatpak on top and/or backported apps will serve us well.
I think the flatpak part of such plan can be ready for our users no sooner than 6-12 months if we start invest seriously in developing maintenance for it now!
What needs to be done in your estimation Jonas? I run PureOS green and have a GNOME 3.32 runtime right now.
First, make sure we fully understand all that it involves to be a full self-contained distributor - as opposed to be in the slipstream if a giant like Debian. As mentioned earlier that includes licensing and security tracking, but that is just scratching the surface. Then (or in parallel), design how we intend such distribution of "upper" parts to integrate with "core" parts flowing in from debian. Then, implement infrastructure to manage all involved. Then, test for some time that it all works. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On Thu, 2019-03-21 at 18:34 +0100, Jonas Smedegaard wrote:
In addition, things like Geary are already flatpak'd. I'm running a 3.32 version of Geary here on PureOS Green.
Question with flatpak is not if possible to execute installed programs. but how we handle QA aspects we then no longer get from Debian - licensing and security fixes and more, for all parts also all linked in libraries and included media files etc., and when we have matured our handling to a level we dare declare stable towards our users.
QA - our upstream has a process for QA. We can contribute there by doing more QA on our contributions to upstream but also in using the upstream software. Licensing - GNOME is a GNU project and considered Free Software, so for the core apps I see no issue. For other applications, we already have a plan for checking licensing in our curation policies. This is a focus of the work on PureOS store in the near term. Security fixes - this needs further discussion. For apps coming from GNOME we ought to more closely coordinate with GNOME and their security policeis (at least until those packages are in Debian but a consistent coordination will likely help in a lot of ways. I intend to talk to Sri this weekend at LibrePlanet so we can develop a set of relevant contacts and perhaps setup regular meetings.
What is not yet stable in Debian testing is the system as a whole. Packages should be in usable form already when uploaded to unstable!
If we choose to use Debian stable for some parts and flatpak and/or backports and/or home-maintained packages for some parts, then depending on how well we _MAINTAIN_ that whole construct we may end up fooling ourselves into having an expensive to maintain burden which is (different but) no better than Debian testing.
I think we'll be more able to make an evaluation with data. Right now it's hard to say how the base distro + flatpak setup works, even though some companies are betting their entire distro on this setup. Still, lots of question marks remain as you stated Jonas. Integration is also a question; how will the data for various apps get passed around? Do all apps follow the LFS or do we follow the XDG standards? Until we have more data we don't know what is feasible or not. But we know today that we have disruptive changes that have a direct impact on the sustainability of our project. If we can address those disruptions and make life easier for users, then we're doing our part to ensure high-quality, convenient Free Software is in the hands of users. Best, Jeremiah
On 20/03/2019 12:47, Jonas Smedegaard wrote:
Quoting François Téchené (2019-03-20 12:09:38)
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?
Well, that just represents priorities. It just means that Stability is the top priority so we must make sure that Usability improvements don't break Stability and that new features don't break Usability and Stability. It doesn't have to be perfect, it is just a rule of thumbs that we can implement the best we can.
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).
No, what I mean is that we are not just a Debian mirror but we are developing projects (GNOME) in order to build the experience we wish to give to the Librem customers. This is not only for the phone but also for the Laptops. It is what my workflow proposal is underlining. The fact of being a mirror of Debian stable for everything we don't develop (the core system) while adding, on top of that stable base, up to date versions of what we put our effort on => GNOME So you should translate that to basing PureOS on Debian stable, then porting, after making sure that new features don't break stability, GNOME 3.32 to that stable base. Cheers, François -- https://puri.sm
Quoting François Téchené (2019-03-20 17:24:23)
On 20/03/2019 12:47, Jonas Smedegaard wrote:
Quoting François Téchené (2019-03-20 12:09:38)
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?
Well, that just represents priorities. It just means that Stability is the top priority so we must make sure that Usability improvements don't break Stability and that new features don't break Usability and Stability. It doesn't have to be perfect, it is just a rule of thumbs that we can implement the best we can.
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).
No, what I mean is that we are not just a Debian mirror but we are developing projects (GNOME) in order to build the experience we wish to give to the Librem customers. This is not only for the phone but also for the Laptops.
It is what my workflow proposal is underlining. The fact of being a mirror of Debian stable for everything we don't develop (the core system) while adding, on top of that stable base, up to date versions of what we put our effort on => GNOME
So you should translate that to basing PureOS on Debian stable, then porting, after making sure that new features don't break stability, GNOME 3.32 to that stable base.
Let me try rephrase to something I can recognize as actionable: I translate it to basing PureOS on Debian stable, not Debian testing, missing out on GNOME 3.32 and libhandy at first but winning that back as soon as we have the resources (manpower, infrastructure, etc.) for maintaining the needed delta from Debian. NB: I am not convinced that above is best for us to do¹, only trying here to align design team needs with PureOS team abilities. Personally I believe strongly in aligning very closely with Debian - differentiating from Debian only in *choices* but not code content. I believe that by getting _closer_ to Debian, we can with _little_ manpower manage _two_ flavors of PureOS: * PureOS 8.0 "green" - rolling release based on Debian testing * PureOS 10.0 "blue" - a mature OS based on Debian stable *both* flavors would follow exact same design principles. Laptops can choose either, phones can only use "green" for now. Debian will eventually support flatpak and ostree and whatever. When they do, we can consider embracing that. If we need it sooner, then we can step up and pay developers (in-house as we do with the phone team, or by directly hiring Debian developers, or whatever) to speed up development until mature enough that Debian adopts it. It is to me *not* an option for PureOS to embrace features Debian cannot adopt. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On 20/03/2019 18:51, Jonas Smedegaard wrote:
Quoting François Téchené (2019-03-20 17:24:23)
On 20/03/2019 12:47, Jonas Smedegaard wrote:
Quoting François Téchené (2019-03-20 12:09:38)
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?
Well, that just represents priorities. It just means that Stability is the top priority so we must make sure that Usability improvements don't break Stability and that new features don't break Usability and Stability. It doesn't have to be perfect, it is just a rule of thumbs that we can implement the best we can.
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).
No, what I mean is that we are not just a Debian mirror but we are developing projects (GNOME) in order to build the experience we wish to give to the Librem customers. This is not only for the phone but also for the Laptops.
It is what my workflow proposal is underlining. The fact of being a mirror of Debian stable for everything we don't develop (the core system) while adding, on top of that stable base, up to date versions of what we put our effort on => GNOME
So you should translate that to basing PureOS on Debian stable, then porting, after making sure that new features don't break stability, GNOME 3.32 to that stable base.
Let me try rephrase to something I can recognize as actionable:
I translate it to basing PureOS on Debian stable, not Debian testing, missing out on GNOME 3.32 and libhandy at first but winning that back as soon as we have the resources (manpower, infrastructure, etc.) for maintaining the needed delta from Debian.
OK, I misunderstood and it is clearer now.
NB: I am not convinced that above is best for us to do¹, only trying here to align design team needs with PureOS team abilities.
Personally I believe strongly in aligning very closely with Debian - differentiating from Debian only in *choices* but not code content.
I believe that by getting _closer_ to Debian, we can with _little_ manpower manage _two_ flavors of PureOS:
* PureOS 8.0 "green" - rolling release based on Debian testing * PureOS 10.0 "blue" - a mature OS based on Debian stable
*both* flavors would follow exact same design principles.
Laptops can choose either, phones can only use "green" for now.
Having 2 flavours of PureOS would be fine for me if we were a Software company making PureOS as a product. However, we are a computers manufacturer and PureOS is a component of our product, which is the Librem computer. In my understanding, our big vision is to make computers that target the human beings (period). A wide majority of the people don't care about the OS component of a computer. Some of them don't even know what an OS is. They just know that if they buy that particular computer, after they switch it on, they will see that particular human interface. Therefore, having to understand the difference and choosing between green and blue, is impossible for a big part of human beings. For the technical ones, PureOS green won't be more interesting than Debian testing... or Debian Sid, or Parabola... So we should focus on making a single distribution that is the OS component of our computers and not planing on putting our effort on supporting several flavors of PureOS for the long term. I understand that it may be technically the only way for us to go, in the short term, but it shouldn't be the long term plan.
Debian will eventually support flatpak and ostree and whatever. When they do, we can consider embracing that. If we need it sooner, then we can step up and pay developers (in-house as we do with the phone team, or by directly hiring Debian developers, or whatever) to speed up development until mature enough that Debian adopts it. It is to me *not* an option for PureOS to embrace features Debian cannot adopt.
I just give you my vision from a UX design perspective. Debian features are not my area. François -- https://puri.sm
Quoting François Téchené (2019-03-21 13:58:25)
On 20/03/2019 18:51, Jonas Smedegaard wrote:
Let me try rephrase to something I can recognize as actionable:
I translate it to basing PureOS on Debian stable, not Debian testing, missing out on GNOME 3.32 and libhandy at first but winning that back as soon as we have the resources (manpower, infrastructure, etc.) for maintaining the needed delta from Debian.
OK, I misunderstood and it is clearer now.
NB: I am not convinced that above is best for us to do¹, only trying here to align design team needs with PureOS team abilities.
Personally I believe strongly in aligning very closely with Debian - differentiating from Debian only in *choices* but not code content.
I believe that by getting _closer_ to Debian, we can with _little_ manpower manage _two_ flavors of PureOS:
* PureOS 8.0 "green" - rolling release based on Debian testing * PureOS 10.0 "blue" - a mature OS based on Debian stable
*both* flavors would follow exact same design principles.
Laptops can choose either, phones can only use "green" for now.
Having 2 flavours of PureOS would be fine for me if we were a Software company making PureOS as a product. However, we are a computers manufacturer and PureOS is a component of our product, which is the Librem computer.
In my understanding, our big vision is to make computers that target the human beings (period). A wide majority of the people don't care about the OS component of a computer. Some of them don't even know what an OS is. They just know that if they buy that particular computer, after they switch it on, they will see that particular human interface.
Therefore, having to understand the difference and choosing between green and blue, is impossible for a big part of human beings.
For the technical ones, PureOS green won't be more interesting than Debian testing... or Debian Sid, or Parabola...
So we should focus on making a single distribution that is the OS component of our computers and not planing on putting our effort on supporting several flavors of PureOS for the long term.
I understand that it may be technically the only way for us to go, in the short term, but it shouldn't be the long term plan.
Hmm, I realize now that you made this very same point in your initial post, which I understood but forgot in my last part above. Sorry! Flavors are needed technically even if not conceptually, however, as you also recognize here above. Let me try unite technical and design views: Conceptually we offer one PureOS, but technically one of more flavors. We promote PureOS as a single thing towards our users, but it is possible for them to know the flavor (needed e.g. for bug tracking). Currently we have 2 flavors, one for laptops and one for phones (ignoring additional draft/development flavors not promoted to users). We will continue to have (at least) 2 flavors for (at least) 6 months: Phones need features too unstable even for Debian testing. We can decide to stabilize laptop flavor: Pace of Debian testing slows down during "freeze" and we can choose to "get off the rollercoster" before it speeds up again, by switching to track Debian stable instead. We get this option only once every 2-4 years during each Debian freeze period. If we stay on the rollercoaster then we can likely get the laptop and phone flavors closer to each other within a year, but we CANNOT realistically STABILIZE either of them within a year. We can decide to "make our own slow rollercoaster" with a rhythm of e.g. 6 months, instead our options at Debian or either 6 hours or 2-4 years. Developing a "rollercoaster" is a far more complex journey than choosing between Debian stable and Debian testing, however, so we can spend resources on that now but we cannot expect to have available to us the choice of _using_ that until maybe 6-12 months later. Also using our own "rollercoaster" is far more resource demanding than leaning on Debian. We can decide to "make our own split reality" where core parts follow Debian (or our own rollercoaster when ready) and other parts ar pulled in from elsewhere - e.g. GNOME project provides GNOME parts. From we take such a decision and until we can offer it to our users takes time. Time to develop and test how we ensure that our users are... ours - i.e. how we can possibly handle bugs in those parts provided not by us. Or if those "upper" parts _are_ provided by us then we need to develop and test our procedures to do that, and invest in resources to do it. Only when that is established we have the choice of _using_ such "split reality". Hope above framing of options makes it possible for both tech and design folks to discuss further together (and that everyone agrees on those options being the ones on the table now). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On 3/21/19 11:01 AM, Jonas Smedegaard wrote:
Quoting François Téchené (2019-03-21 13:58:25)
On 20/03/2019 18:51, Jonas Smedegaard wrote:
Let me try rephrase to something I can recognize as actionable:
I translate it to basing PureOS on Debian stable, not Debian testing, missing out on GNOME 3.32 and libhandy at first but winning that back as soon as we have the resources (manpower, infrastructure, etc.) for maintaining the needed delta from Debian.
OK, I misunderstood and it is clearer now.
NB: I am not convinced that above is best for us to do¹, only trying here to align design team needs with PureOS team abilities.
Personally I believe strongly in aligning very closely with Debian - differentiating from Debian only in *choices* but not code content.
I believe that by getting _closer_ to Debian, we can with _little_ manpower manage _two_ flavors of PureOS:
* PureOS 8.0 "green" - rolling release based on Debian testing * PureOS 10.0 "blue" - a mature OS based on Debian stable
*both* flavors would follow exact same design principles.
Laptops can choose either, phones can only use "green" for now.
Having 2 flavours of PureOS would be fine for me if we were a Software company making PureOS as a product. However, we are a computers manufacturer and PureOS is a component of our product, which is the Librem computer.
In my understanding, our big vision is to make computers that target the human beings (period). A wide majority of the people don't care about the OS component of a computer. Some of them don't even know what an OS is. They just know that if they buy that particular computer, after they switch it on, they will see that particular human interface.
Therefore, having to understand the difference and choosing between green and blue, is impossible for a big part of human beings.
For the technical ones, PureOS green won't be more interesting than Debian testing... or Debian Sid, or Parabola...
So we should focus on making a single distribution that is the OS component of our computers and not planing on putting our effort on supporting several flavors of PureOS for the long term.
I understand that it may be technically the only way for us to go, in the short term, but it shouldn't be the long term plan.
Hmm, I realize now that you made this very same point in your initial post, which I understood but forgot in my last part above. Sorry!
Flavors are needed technically even if not conceptually, however, as you also recognize here above. Let me try unite technical and design views:
Conceptually we offer one PureOS, but technically one of more flavors. We promote PureOS as a single thing towards our users, but it is possible for them to know the flavor (needed e.g. for bug tracking).
Currently we have 2 flavors, one for laptops and one for phones (ignoring additional draft/development flavors not promoted to users).
Let me throw another wrench into the gears. We have servers on the horizon. I would say priority has risen to roll these out in less than 6 months but we have something in the works now to sell. How does this affect things?
We will continue to have (at least) 2 flavors for (at least) 6 months: Phones need features too unstable even for Debian testing.
We can decide to stabilize laptop flavor: Pace of Debian testing slows down during "freeze" and we can choose to "get off the rollercoster" before it speeds up again, by switching to track Debian stable instead. We get this option only once every 2-4 years during each Debian freeze period.
If we stay on the rollercoaster then we can likely get the laptop and phone flavors closer to each other within a year, but we CANNOT realistically STABILIZE either of them within a year.
We can decide to "make our own slow rollercoaster" with a rhythm of e.g. 6 months, instead our options at Debian or either 6 hours or 2-4 years. Developing a "rollercoaster" is a far more complex journey than choosing between Debian stable and Debian testing, however, so we can spend resources on that now but we cannot expect to have available to us the choice of _using_ that until maybe 6-12 months later. Also using our own "rollercoaster" is far more resource demanding than leaning on Debian.
We can decide to "make our own split reality" where core parts follow Debian (or our own rollercoaster when ready) and other parts ar pulled in from elsewhere - e.g. GNOME project provides GNOME parts. From we take such a decision and until we can offer it to our users takes time. Time to develop and test how we ensure that our users are... ours - i.e. how we can possibly handle bugs in those parts provided not by us. Or if those "upper" parts _are_ provided by us then we need to develop and test our procedures to do that, and invest in resources to do it. Only when that is established we have the choice of _using_ such "split reality".
Hope above framing of options makes it possible for both tech and design folks to discuss further together (and that everyone agrees on those options being the ones on the table now).
- Jonas
- Omar
_______________________________________________ Pureos-project mailing list Pureos-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
Quoting Omar (2019-03-21 18:12:23)
On 3/21/19 11:01 AM, Jonas Smedegaard wrote:
Conceptually we offer one PureOS, but technically one of more flavors. We promote PureOS as a single thing towards our users, but it is possible for them to know the flavor (needed e.g. for bug tracking).
Currently we have 2 flavors, one for laptops and one for phones (ignoring additional draft/development flavors not promoted to users).
Let me throw another wrench into the gears. We have servers on the horizon. I would say priority has risen to roll these out in less than 6 months but we have something in the works now to sell. How does this affect things?
Quite interesting! What more specifically do we have in works now? Possibly we can simply have servers use same flavor as laptops or phones - depending on both which hardware and which software needs we are talking about. If e.g. we want to offer services with AI logic relying on GPU processing running on hardware similar to the phones, then it gets challenging to stabilize. If we "just" want to offer Librem One services in a box, then it _may_ gets challenging to stabilize, if it includes parts like Riot Web. Please tell more - I have looked forward to this since I began working for Purism ~20 moons ago. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On 3/21/19 1:41 PM, Jonas Smedegaard wrote:
Quoting Omar (2019-03-21 18:12:23)
On 3/21/19 11:01 AM, Jonas Smedegaard wrote:
Conceptually we offer one PureOS, but technically one of more flavors. We promote PureOS as a single thing towards our users, but it is possible for them to know the flavor (needed e.g. for bug tracking).
Currently we have 2 flavors, one for laptops and one for phones (ignoring additional draft/development flavors not promoted to users). Let me throw another wrench into the gears. We have servers on the horizon. I would say priority has risen to roll these out in less than 6 months but we have something in the works now to sell. How does this affect things? Quite interesting! What more specifically do we have in works now?
Possibly we can simply have servers use same flavor as laptops or phones - depending on both which hardware and which software needs we are talking about.
If e.g. we want to offer services with AI logic relying on GPU processing running on hardware similar to the phones, then it gets challenging to stabilize.
If we "just" want to offer Librem One services in a box, then it _may_ gets challenging to stabilize, if it includes parts like Riot Web. This is on the roadmap. A 'Librem Box' with similar specs to our laptop but probably 8th gen cpu. See here and issue #1: https://source.puri.sm/Products/Librem_Hardware/librembox. With higher MOQs required, the rack server is taking precedence. I think the easy part for the Librem Box is the hardware. I'll leave the hard part to you guys ;) <https://source.puri.sm/Products/Librem_Hardware/librembox> Please tell more - I have looked forward to this since I began working for Purism ~20 moons ago. Great! For now, looking at using a 1U rackmount Xeon-D motherboard with Coreboot and a Librem Key thrown into the mix. Any suggestions or ideas you would like to see, please throw them my way! More to come...
- Jonas
- Omar
Quoting Omar (2019-03-22 01:06:03)
On 3/21/19 1:41 PM, Jonas Smedegaard wrote:
Quoting Omar (2019-03-21 18:12:23)
On 3/21/19 11:01 AM, Jonas Smedegaard wrote:
Conceptually we offer one PureOS, but technically one of more flavors. We promote PureOS as a single thing towards our users, but it is possible for them to know the flavor (needed e.g. for bug tracking).
Currently we have 2 flavors, one for laptops and one for phones (ignoring additional draft/development flavors not promoted to users). Let me throw another wrench into the gears. We have servers on the horizon. I would say priority has risen to roll these out in less than 6 months but we have something in the works now to sell. How does this affect things? Quite interesting! What more specifically do we have in works now?
Possibly we can simply have servers use same flavor as laptops or phones - depending on both which hardware and which software needs we are talking about.
If e.g. we want to offer services with AI logic relying on GPU processing running on hardware similar to the phones, then it gets challenging to stabilize.
If we "just" want to offer Librem One services in a box, then it _may_ gets challenging to stabilize, if it includes parts like Riot Web. This is on the roadmap. A 'Librem Box' with similar specs to our laptop but probably 8th gen cpu. See here and issue #1: https://source.puri.sm/Products/Librem_Hardware/librembox. With higher MOQs required, the rack server is taking precedence. I think the easy part for the Librem Box is the hardware. I'll leave the hard part to you guys ;) <https://source.puri.sm/Products/Librem_Hardware/librembox> Please tell more - I have looked forward to this since I began working for Purism ~20 moons ago. Great! For now, looking at using a 1U rackmount Xeon-D motherboard with Coreboot and a Librem Key thrown into the mix. Any suggestions or ideas you would like to see, please throw them my way! More to come...
From a technical general software standpoint, server hardware close to our existing laptops can use exact same flavor as for the laptops (just using a different install profile than "GNOME desktop").
I envision no major PureOS cost (time, attention, infrastructure) in offering to ship such servers with FreedomBox preinstalled. If we choose to stabilize the flavor we now use for laptops, then we can still offer a FreedomBox install: It is already available in PureOS. Adapting FreedomBox to include more/other services more closely matching our Librem One offering, then that will need time and resources. Adapting user interface of FreedomBox to more closely align with our design principles should be possible, but I expect that to require resources as well - I am happy to look into that closer with the desing team as needed. I don't have further ideas than already mentioned in your referenced issue, but please keep me in the loop! If/when we open up to also explore smaller fanless server options, I have more ideas, as that has been my main focus the past ~15 years. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On Fri, 2019-03-22 at 10:39 +0100, Jonas Smedegaard wrote:
Quoting Omar (2019-03-22 01:06:03)
On 3/21/19 1:41 PM, Jonas Smedegaard wrote:
Quoting Omar (2019-03-21 18:12:23)
On 3/21/19 11:01 AM, Jonas Smedegaard wrote:
Conceptually we offer one PureOS, but technically one of more flavors. We promote PureOS as a single thing towards our users, but it is possible for them to know the flavor (needed e.g. for bug tracking).
Currently we have 2 flavors, one for laptops and one for phones (ignoring additional draft/development flavors not promoted to users). Let me throw another wrench into the gears. We have servers on the horizon. I would say priority has risen to roll these out in less than 6 months but we have something in the works now to sell. How does this affect things?
Servers are usually "headless" which means they don't usually need a GUI. This is because they tend to get racked in some remote data with the only access a OpenSSH port. This makes things a lot easier since a "vanilla" instance of PureOS server software, without a GUI, means we can use something very close to our upstream Debian. Debian is likely the most widely used server OS so if we don't do much (I imagine we'll add PureBoot and perhaps other things) we should be able to create and maintain a server flavor of PureOS fairly easily. There are early discussions with Dan Kinon about this, hopefully we'll have more when the hardware's ready and when Dan gets a free moment, I understand he's very busy. :-)
Quite interesting! What more specifically do we have in works now?
Possibly we can simply have servers use same flavor as laptops or phones - depending on both which hardware and which software needs we are talking about.
If e.g. we want to offer services with AI logic relying on GPU processing running on hardware similar to the phones, then it gets challenging to stabilize.
If we "just" want to offer Librem One services in a box, then it _may_ gets challenging to stabilize, if it includes parts like Riot Web. This is on the roadmap. A 'Librem Box' with similar specs to our laptop but probably 8th gen cpu. See here and issue #1: https://source.puri.sm/Products/Librem_Hardware/librembox. With higher MOQs required, the rack server is taking precedence. I think the easy part for the Librem Box is the hardware. I'll leave the hard part to you guys ;) <https://source.puri.sm/Products/Librem_Hardware/librembox> Please tell more - I have looked forward to this since I began working for Purism ~20 moons ago. Great! For now, looking at using a 1U rackmount Xeon-D motherboard with Coreboot and a Librem Key thrown into the mix. Any suggestions or ideas you would like to see, please throw them my way! More to come...
From a technical general software standpoint, server hardware close to our existing laptops can use exact same flavor as for the laptops (just using a different install profile than "GNOME desktop").
+1
I envision no major PureOS cost (time, attention, infrastructure) in offering to ship such servers with FreedomBox preinstalled.
+1 It's hard to say how much work porting Pureboot to Xeon is, at least for me, perhaps for other's it's easier.
If we choose to stabilize the flavor we now use for laptops, then we can still offer a FreedomBox install: It is already available in PureOS.
Adapting FreedomBox to include more/other services more closely matching our Librem One offering, then that will need time and resources.
Adapting user interface of FreedomBox to more closely align with our design principles should be possible, but I expect that to require resources as well - I am happy to look into that closer with the desing team as needed.
+1
I don't have further ideas than already mentioned in your referenced issue, but please keep me in the loop!
If/when we open up to also explore smaller fanless server options, I have more ideas, as that has been my main focus the past ~15 years.
I think a set of specifications from your side would be very valuable when it comes time to making that decision. Would you be willing to draw something like that up? Cheers, Jeremiah
Quoting Jeremiah C. Foster (2019-03-22 14:15:56)
On Fri, 2019-03-22 at 10:39 +0100, Jonas Smedegaard wrote:
Quoting Omar (2019-03-22 01:06:03)
On 3/21/19 1:41 PM, Jonas Smedegaard wrote:
Quoting Omar (2019-03-21 18:12:23)
Let me throw another wrench into the gears. We have servers on the horizon. I would say priority has risen to roll these out in less than 6 months but we have something in the works now to sell. How does this affect things? Quite interesting! What more specifically do we have in works now?
[...]
This is on the roadmap. A 'Librem Box' with similar specs to our laptop but probably 8th gen cpu. See here and issue #1: https://source.puri.sm/Products/Librem_Hardware/librembox.
[...]
I don't have further ideas than already mentioned in your referenced issue, but please keep me in the loop!
If/when we open up to also explore smaller fanless server options, I have more ideas, as that has been my main focus the past ~15 years.
I think a set of specifications from your side would be very valuable when it comes time to making that decision. Would you be willing to draw something like that up?
I meant "please keep me in the loop, so I can contribute opinions and ideas while decisions are being made rather than afterwards when someone points me to yet another issue tracker with artifacts of past decision making" (not "keep me in the loop for my personal amusement"). So if by "draw something up" you mean a conversation like this email thread then yes certainly I would love to do that (and tried but evidently failed indicating my interest in that already)! If however you mean make some sort of report, then I am more hesitant, as I am not good at writing larger coherent texts on my own... :-/ (...and if you literally mean "drawing" then you don't want that) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
participants (6)
-
François Téchené -
Jeremiah C. Foster -
Jonas Smedegaard -
Nicole Faerber -
Omar -
Tobias Bernard