policy for level of stability of PureOS stable
How stable is PureOS stable a.k.a. amber? Which criteria for permitting new packages to get included? Which criteria for permitting existing packages to get updated? Do I just use my gut feeling? Concretely, David Seaward wants ldh-gui-suite added, but makes sense to me to address this generally, eary on. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
On Thu, 2019-10-24 at 20:11 +0200, Jonas Smedegaard wrote:
Concretely, David Seaward wants ldh-gui-suite added, but makes sense to me to address this generally, eary on.
To expand on this, I would ideally like to keep releasing the latest stable versions of all Librem One / Liberty packages (including third- party packages) to the latest stable version of PureOS. So if we released 1.0 today, we'd update amber. If we released 2.0 next month, we'd update amber. If we released 3.0 in two years time, we'd update byzantium (assuming it was now "stable"). I imagine that this is the same for core phone packages, except that Librem One packages target both desktop and phone. Happy with any solution that makes this possible. I don't think Flatpak will solve this because we need system-level integration (and this integration requirement will only expand). Thanks for raising this Jonas! Regards, David
On Thu, 2019-10-24 at 21:55 +0200, David Seaward wrote:
On Thu, 2019-10-24 at 20:11 +0200, Jonas Smedegaard wrote:
Concretely, David Seaward wants ldh-gui-suite added, but makes sense to me to address this generally, eary on.
I raised this recently and the feedback was that PureOS should considered directly under our (Purism's) control. So, for example, we can release Liberty packages at any rate we (the Librem One team) are comfortable maintaining. Obvious issues that spring to mind are: 1. Is the package ready for an everyday audience? Here I'd like to confirm we have some kind of QA process before a Liberty package hits PureOS stable. 2. Do we require updates to dependency packages? We must strenuously avoid this, otherwise we have to maintain these packages ourselves, rather than inheriting Debian's maintenance effort. Development dependencies must be pinned to match whatever is available in PureOS stable. 3. How do we handle releases to PureOS stable and PureOS next? Liberty packages MUST always work on PureOS stable. They SHOULD work on PureOS next. If they stop working on PureOS next, we aim to get them working on both again, but only as resources allow. Jonas, are there other maintenance concerns that I've overlooked? Regards, David
Quoting David Seaward (2019-11-04 20:55:31)
On Thu, 2019-10-24 at 21:55 +0200, David Seaward wrote:
On Thu, 2019-10-24 at 20:11 +0200, Jonas Smedegaard wrote:
Concretely, David Seaward wants ldh-gui-suite added, but makes sense to me to address this generally, eary on.
I raised this recently and the feedback was that PureOS should considered directly under our (Purism's) control. So, for example, we can release Liberty packages at any rate we (the Librem One team) are comfortable maintaining.
Obvious issues that spring to mind are:
1. Is the package ready for an everyday audience?
Here I'd like to confirm we have some kind of QA process before a Liberty package hits PureOS stable.
2. Do we require updates to dependency packages?
We must strenuously avoid this, otherwise we have to maintain these packages ourselves, rather than inheriting Debian's maintenance effort. Development dependencies must be pinned to match whatever is available in PureOS stable.
3. How do we handle releases to PureOS stable and PureOS next?
Liberty packages MUST always work on PureOS stable. They SHOULD work on PureOS next. If they stop working on PureOS next, we aim to get them working on both again, but only as resources allow.
Jonas, are there other maintenance concerns that I've overlooked?
4. How do we ensure packages are truly _maintained_ (not only added)? What are criteria for _removing_ packages? How to we ensure those criteria is met? How do we detect packages weakly maintained? What to do if we know about weakly maintained packages but lack the resources to address the issues? 5. Wat about security? Who correlates our packages with CVEs? What to do by whom when a package has security flaws? ...which doesn't get addressed in a timely fashion? ...which involves embargoing? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
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 >:>
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@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
Hi, On Thu, Oct 24, 2019 at 08:11:15PM +0200, Jonas Smedegaard wrote:
How stable is PureOS stable a.k.a. amber?
Which criteria for permitting new packages to get included?
Which criteria for permitting existing packages to get updated?
Do I just use my gut feeling?
Concretely, David Seaward wants ldh-gui-suite added, but makes sense to me to address this generally, eary on.
The policy i've followed so far (which is more of a lower bound is): - packages uploaded to amber-updates must not be a dependency of anything already in amber proper (e.g.phosh, phoc, libhandy) depend on stuff in amber but nothing in amber depends on it) - packages in amber-updates may depend on other packages in amber-updates - packages uploaded to amber-updates must not (knowingly) change behaviour of anything in amber Cheers, -- Guido
participants (4)
-
David Seaward -
Guido Günther -
Jeremiah C. Foster -
Jonas Smedegaard