On Mon, 2017-03-13 at 15:32 +0000, Robert McQueen wrote:
On 11/03/17 09:44, Richard Hughes wrote:Endless has a [custom update daemon](https://github.com/endlessm/ eos-updater) which...now that I look has certainly advanced a lot. They may have ideas/requests/design input.Hey Endless people! How do you show OS release notes to the user?We don't at the moment. :( Typically our release notes are finalised in the days between tagging the release in our staging repo but before it's pushed to our production repo, in parallel with the image and static delta builds, etc. So if we had to presume/assume that the release notes were ready and translated to be checked in to ostree, we would probably be stuck. I know we do want to have the release notes shown to people before/after (?) an upgrade, don't know if we'd got as far as the mechanism - not sure if that's planned yet. Cosimo might know.
I think we could add the release notes as detached metadata on the commit for the release. Detached metadata can be added to a commit any time, without changing the commit ref. This does mean that the release notes would have to have their own GPG signature, but that’s fine. (That said, I can find very little documentation on detached metadata, so I might be misinterpreting its usefulness here.)
This might also be an opportune time to mention my nefarious plan that maybe with a hackfest, we could review/remove Endless-isms from eos-updater and proffer it as a battle-tested candidate to become the ostree update daemon. :) Philip has just been landing Avahi server/client code which Kinvolk worked on for us last year, which means we've got "fatter" in the eos-updater layer and it's worth us comparing notes to see what can be upstreamed where - this is useful stuff which is really not Endless specific so we want it out in the wider world. (Our largest Endless-ism was our server indirection mechanism to look up refs based on the hardware we're running on, but we took that out because combining that correctly/safely with Avahi updates is a real noodle baker, and in practice we weren't using it.)
Indeed, now I think the only Endless-isms are the metrics (small amount of code, done on deployment only); and the policy about when to poll and pull updates. I would be very keen to make eos-updater more generic. Philip
That said - I'm not sure if we have the cycles to do _all_ of that right now, but Philip is about to start thinking about applying OS update schedule/policy to our Flatpak runtimes, and also sharing/downloading runtimes/apps using the Avahi machinery. This convergence may well involve having GNOME Software take over being the UI for our OS updater, or eos-updater taking over some of the fetching (that _is_ a little more Endless specific, as our /var/lib/flatpak/repo is /ostree/repo too), etc - so this is a very opportune time to talk about what eos-updater would need to have to become ostree-daemon, and then we can dig into these kind of integration points with a little more generic interest. Cheers, Rob ..................................................................... ... Robert McQueen | +1.415.413.4159 | Endless <http://endlessm.com/>
Attachment:
signature.asc
Description: This is a digitally signed message part