[PureOS] policy for level of stability of PureOS stable

[Jeremiah C. Foster]

On Tue, 2019-11-05 at 22:05 +0200, David Seaward wrote:
> On Tue, 2019-11-05 at 11:55 +0100, Jonas Smedegaard wrote:
> > Quoting David Seaward (2019-11-04 20:55:31)
> > > 1. Is the package ready for an everyday audience?
> > > 
> > > ...
> > > 
> > > 2. Do we require updates to dependency packages?
> > > 
> > > ...
> > > 
> > > 
> > > 3. How do we handle releases to PureOS stable and PureOS next?
> > > 
> > ...
> > 
> > 4. How do we ensure packages are truly _maintained_ (not only
> > added)?
> > 
> > ...
> > 
> > 5. What about security?
> 
> In the context of Liberty packages, I think answers to all of these
> boil down to the Librem One team taking responsibility. Functionally
> this means any problems should be directed to my inbox, and I'll
> figure
> out who can handle them.

One thing that might be useful is having "team maintainership" of the
liberty apps. This solves single point of failure issues, at least in
meat space. We may want to create a shared mailing list for the apps? 

> Before diving into details, I think a basic principle would be:
> 
> * Liberty packages will rely on the existing version of packages
> already in PureOS stable. For example, we will rely on the existing
> versions of Python, GNOME or any Python libraries.

+1

> * We may need to add new thid-party dependencies, e.g. Python
> libraries, but will aim to minimise these. Such dependencies should
> be
> considered under our team control.

+1

> * We will add new software built by our team. These packages should
> be
> considered under our team control.

+1

> Thus, it looks to me like there will be a Liberty "layer" on top of
> "PureOS stable". Is this sensible, and is there an existing mechanism
> to maintain a layer like this?

What is the "layer" here? Is it Liberty apps and their dependencies?

> upstream > Debian > magical mechanism > PureOS stable

We can of course use the CI to build upstream > PureOS {stable,testing}
simply by creating separate branches (one for debian and one for
pureos) that hold the packaging and package for each distro
respectively thereby building two packages for two separate distros
simultaneously! 

Once the path into Debian is established, we can use that if we prefer,
but we can always use the pureos package to *quickly* update the
package for security or other reasons. 

> Additional questions:
> 
> * Is there a single Debian release we will package against? I'd
> prefer
> to avoid shifting dependencies.

I'd just chose unstable and let the chips fall where they may.

> * I'm guessing the magical mechanism is in fact made up of multiple
> components? If we have to define a pipeline of existing components,
> I'm
> happy to name it for future reference -- although I think another
> project uses Bifröst ;)

I think the best way is to package each of the components if necessary
and then package each app individually. 

I'm happy to help start out the packaging if someone points me to the
build instructions. :-)

Cheers,

Jeremiah

> Regards,
> David
> 
> P.S. I realise this doesn't exactly answer the original question, but
> I'm very biased >:>
> 
> _______________________________________________
> PureOS-project mailing list
> PureOS-project at lists.puri.sm
> https://lists.puri.sm/listinfo/pureos-project
-------------- 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/20191106/d57122f9/attachment.sig>