[PureOS] Let's stablize PureoS Green

[Jonas Smedegaard]

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
-------------- 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/20190321/2a7689ad/attachment-0001.sig>