Re: libostree v2017.3

[Colin Walters <walters verbum org>]

On Fri, Mar 10, 2017, at 03:20 PM, Richard Hughes wrote:

> I think using AppStream for this might work for the OS layer, but
> somebody is going to need to write the "release notes" between Fedora
> Atomic 25.0 and 25.1, and then 25.2, and then 25.3 etc. -- which
> probably also need to be translated somewhere. This is obviously
> polish, but important before we can roll it out to regular users.

Wait, sorry - your original question *wasn't* about flatpak, it was
for the ostree-as-host case?  It looks like you know way
more about the flatpak case than I do (which isn't surprising!),
I just assumed we were talking about flatpak.

Assuming then you're talking about the ostree-as-host
case...it bifurcates since there's people using "raw libostree", but
of course I also maintain rpm-ostree which is really tied to
Fedora/CentOS.

If this is then about gnome-software for the host...here's
again where things possibly bifurcate *again*, since what we do for
Atomic Host (the *server* case) might be different from the desktop case.

For Atomic Host, I am not seeing an immediate value in having
translated release notes for example.  My strong inclination
is to use the ostree commit log, and teach the releng infrastructure
to put useful information there.

(You have to keep in mind I've been in a long-running battle
 in the Fedora case to fix the release infrastructure for more basic things, like
 having a release cadence that's not once-a-day, since that basically precludes
 a human writing release notes)

However, we're not interested in gnome-software for Atomic Host
(that's where Cockpit's ostree support would come in).  We're
more looking at the desktop case, right?

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.

If this is about the desktop case, basically I think we're going to
end up with separate gnome-software plugins for rpm-ostree and
eos-updater most likely.  And the data they consume is likely
to be different due to the fact that they consume entirely separate
distributions with different tools.

I'd like to keep open the conversation about having an "official/reference"
"pure ostree" update daemon, which could simplify things.