[PureOS] Bits frm PureOS | Buster edition

[Jeremiah C. Foster]

On Wed, 2019-07-10 at 22:28 +0200, Matthias Klumpp wrote:
> Hey :-)
> Sorry for the delayed reply...
> 
> Am Mo., 8. Juli 2019 um 19:10 Uhr schrieb Jeremiah C. Foster
> <jeremiah.foster at puri.sm>:
> > On Mon, 2019-07-08 at 19:04 +0200, Matthias Klumpp wrote:
> > > [...]
> > > Indeed. As a matter of fact, PureOS green is already tracking
> > > bullseye
> > > at the moment.
> > > If we want a version of PureOS based on Debian stable, that would
> > > have
> > > to be a new suite, otherwise we would throw all of our users out
> > > of
> > > security support immediately.
> > 
> > Why? Buster has security support as well.
> 
> It has, but if green is frozen our users won't get any of the
> updates.
> All of our users will have the "green" suite only in their
> sources.list currently, but that will be frozen and not receive any
> more updates, just like the buster suite is frozen in Debian now.

I see. I thought that Debian stable releases were still rolling, but I
think I'm mistaken. What really happens is that security fixes and
updates get "backported" into stable from testing / unstable?

> Instead, a green-updates and maybe green-security suite needs to be
> created and added to the user's sources.list if they still want to
> receive updates. This is a manual step, and if our users don't know
> about it, they won't receive any updates.

Okay. This makes it a lot clearer to me. I naively thought it happened
automagically.

> There are solutions to this:
> 
> A) Merge updates into the "green" suite.
> This is not really supported in Laniakea (because it's usually a bad
> idea ^^) and will result in us being unable to stop distribution of
> an
> update once it's released, require users to do bigger metadata
> downloads on archive updates, not allow for much access control
> during
> updates and will make it hard for users to opt-out receiving certain
> updates. I don't actually know any distribution that does this.
> 
> B) Implement some hack in a package that every "green" users installs
> (apt?) to rewrite sources.list
> That's also ugly but ensures every sources.list is changed - if the
> script is written well and doesn't have sideeffects.

I'd like to know more about this approach, what does it entail? Would
we; 

1. Create green-updates and green-security
2. Find a way to get all green users to put it in their
/etc/apt/sources.d/ dir?

Perhaps we could do both a simple script and to print clear
instructions in our forum on how to do this. 

> C) Keep "green" as rolling development target, create new suite with
> the released, stable packages and switch PureOS deployment over to
> that for new Librems

Wouldn't it be easier to keep the new suite as 'green'? That way we
would have fewer changes to apt sources lists.

> We'd need a new suite name, 

Another color? :-)

> but other than that this would be similar
> to what Ubuntu does as well. In the long run we might somehow get rid
> of "green" to avoid the additional branching-off of suites when
> releasing a new stable release, or alternatively embrace that step as
> development model.
> Making "green" an alias to the respective current development suite
> of
> PureOS (like testing is an alias for "next Debian stable suite") is
> probably the best solution in this case. That would effectively give
> us a workflow like Ubuntu for making PureOS releases.

I see. I think I understand too.
> 
> I would heavily favour C, so C >> B > A
> That would be the cleanest possible cut we could do.

Agreed.

>  B doesn't feel
> like a great idea, but might be a compromise, A feels like the wrong
> thing to do.

Also agreed. 

> > > There is also the problem of us having advertised PureOS as
> > > (semi)
> > > rolling so far,
> > 
> > I think that we can work with marketing to positively describe the
> > situation. Stability is clearly a more important goal than a
> > rolling
> > release (at least in the internal conversations I've had.)
> > 
> > > and the PureOS team being completely unable to handle
> > > any enterprise stuff with its current manpower.
> > 
> > I don't understand this. We already do this with Green - why can't
> > we
> > continue?
> 
> We will have to track updates to our stable branch but also keep our
> development branch (likely still based on testing) maintained. That
> is
> quite a bit of effort.

Good point. There is a real effort to get more resources around PureOS.

> We do need a development branch both for the phone team, but also for
> testing new changes and adapting our code to work with the next
> release of Debian, so we don't get hit with all the changes once
> Bullseye is released.
> 
> > > We can just about support development of one suite, handling
> > > fixes
> > > and
> > > security support for two would be really really hard.
> > 
> > Surely not impossible though?
> 
> Nothing is impossible ;-)
> But we do need adequate manpower to handle things reliably.
> With Jonas mainly working on services now, we are really short of
> engineers for the OS itself.

+1

Regards,

Jeremiah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190711/e82faf0d/attachment.sig>