[PureOS] Let's stablize PureoS Green

[Jonas Smedegaard]

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
-------------- 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/20190320/647e1925/attachment.sig>