[PureOS] policy for level of stability of PureOS stable
David Seaward
david.seaward at puri.sm
Tue Nov 5 12:05:24 PST 2019
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.
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.
* 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.
* We will add new software built by our team. These packages should be
considered under our team control.
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?
upstream > Debian > magical mechanism > PureOS stable
Additional questions:
* Is there a single Debian release we will package against? I'd prefer
to avoid shifting dependencies.
* 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 ;)
Regards,
David
P.S. I realise this doesn't exactly answer the original question, but
I'm very biased >:>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20191105/297bfb86/attachment.sig>
More information about the PureOS-project
mailing list