On Tue, 2016-03-15 at 14:11 -0400, Matthew Miller wrote:
However, when it gets to the "applications" and
"developer needs"
portions, it's more about possibilities and plans than concrete
steps, which is where I'm worried about the practical aspects.
If we're going to make this as a prototype/demo/toy for F25, with a
goal further out, that's not a problem. But if we want to deliver all
of that by then, we really need to step up in resources. Take a look
at
https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline —
support for ostree-based Workstation is there, but there's nothing
for
application delivery as xdg-apps or the "different installation
mechanism" mentioned in Owen's doc.
Hi Matthew,
One of the main points in my mind is that this isn't for everyone
initially - an ostree based workstation provides strong advantages for
someone who doesn't want their OS to break, but is less useful for
someone who wants the freedom to break their system or to make a big
change to it like switching out the desktop environment.
So I think the messaging around Fedora 25 is that this is a new way
to install Fedora - that it is suitable in some cases, and not in other
cases. And we can start with an even narrower use case.
But that doesn't get us out of having to have some sort of functioning
xdg-app ecosystem - and you are certainly right that is a big hand-
wave, and it's not clear how much we can clear that up for F25. If we
don't have a useful application installation experience, then we
clearly have a prototype not something we can advertise as ready to
use.
We basically need:
* A central registry for xdg-app repositories
* A way of deciding what goes into that registry; the
3rd-party-software proposal is meant to cover that, but basically
just defers the hard part to the working group.
* Perhaps a "bootstrap" repository where we make existing
Fedora applications available as xdg-apps
In terms of a installation mechanism for non-applications, one piece of
it is:
https://blogs.gnome.org/alexl/2015/09/23/playing-games-with-runtime-ext
ensions/
That would be used for proprietary graphics drivers or codecs. (Just
added a link to the documents.) Runtimes and runtime extensions are
pretty similar to applications in the xdg-app world - they are just
ostree trees, so I don't think there is additional release engineering
beyond whatever is needed for applications and runtimes, once we have
that figured out.
Fonts - I don't know at the moment. It may just be a question of making
all the fonts in /usr/share/fonts and ~/.fonts pass through to the
application, though that would isolate users from being able to take
advantage of additional fonts packaged for Fedora.
> As for closer alignment with Atomic, I have heard both your
opinion
> (yes, make this part of the atomic umbrella) and the opposite (no,
> atomic is already too much of a grab bag of stuff). I personally
> think
> aligning with Atomic is the right idea.
Yeah, I hear the grab-bag thing too. I don't think we should put
anything under the name _without_ also have the alignment with
technology. And, the other way around, it's a good idea to align the
technology even if we don't use the name.
For example, if we could produce xdg-apps through Fedora Release
Engineering using the same build pipeline that's being worked on for
Docker images, the work required would collapse to creating
documentation for how to do that and any related policies, rather
than a whole *new* releng change.
That sounds like a good idea to keep things sane on the Fedora side,
but I doubt many users understand the complexity of release engineering
and would pay attention to that.
Alignment that make reusing the name makes sense, to me, would be:
* Consistent talking points about what advantages "Atomic" brings -
stability, isolation, etc.
* Good support in the Workstation product for developing applications
to deploy on Atomic Host.
It certainly would be a problem if someone downloaded "Fedora Atomic
Workstation" then found they need to reinstall a non-atomic "Fedora
Workstation" to actually write apps for Atomic...
- Owen