[PureOS] Let's stablize PureoS Green

Omar omar.aboulhosn at puri.sm
Thu Mar 21 10:12:23 PDT 2019


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 at lists.puri.sm
> https://lists.puri.sm/listinfo/pureos-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190321/42a185b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190321/42a185b9/attachment.sig>


More information about the Pureos-project mailing list