<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 3/14/19 1:52 PM, Jonas Smedegaard
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:155258957784.19101.8230750573943611153@auryn.jones.dk">
      <pre class="moz-quote-pre" wrap="">Quoting Jeremiah C. Foster (2019-03-14 18:57:44)
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">What do those folks on this mailing list think? Should we keep PureOS 
Green on Debian (Buster) Stable?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Above is strongly tied the related question of what to do about cravings 
for exciting new $stuff as Buster (non-)evolves to become steadily more 
boring over its multi-year lifespan.
</pre>
    </blockquote>
    <p>I might give you another perspective from an intermediate user.
      What some of you 'OS nerds' ;) consider boring, I'm guessing the
      majority of our customers see it as a very functional, cool as-is
      tool to get things done. As long as privacy and security
      improvements don't get stagnant... And any customer that may be as
      advanced as you guys, will know the ways to make it un-boring :)</p>
    <blockquote type="cite"
      cite="mid:155258957784.19101.8230750573943611153@auryn.jones.dk">
      <pre class="moz-quote-pre" wrap="">
Do we...

 a) Tell users to wait for it to become boring enough?
 b) Maintain a local fork as .deb in PureOS for each wish?
 c) Maintain a local flatpak for each wish?
 d) Tell users to include .deb/flatpack maintained elsewhere?

With a) I say yes let's do it.  But I expect others in the company to 
not really want that option for several years, not even for enterprise 
users. Testing that is simple: Imagine PureOS being Stretch until 6 
months from now (i.e. until Buster becomes boring _and_ we finish 
testing that it really truly is boring also with our adaptations).

With b) I say no: We lack manpower, procedures, and infrastructure to 
handle that - including security tracking but also other things.

With c) I say that those responsible for flatpack maintenance need to 
evaluate when they are ready - including security tracking but also 
other things.  Which implies that it is a no if PureOS team has that 
responsibility.

With d) I say no: It is irresponsible of us to point our users 
elsewhere.


 - Jonas
</pre>
    </blockquote>
     - Omar<br>
    <blockquote type="cite"
      cite="mid:155258957784.19101.8230750573943611153@auryn.jones.dk">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Pureos-project mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pureos-project@lists.puri.sm">Pureos-project@lists.puri.sm</a>
<a class="moz-txt-link-freetext" href="https://lists.puri.sm/listinfo/pureos-project">https://lists.puri.sm/listinfo/pureos-project</a>
</pre>
    </blockquote>
  </body>
</html>