The Workstation WG meeting is scheduled for this Wednesday, 2016-Mar-16 at 1400 UTC (10:00 EDT, 15:00 CET). This agenda is open for additions/corrections; please send by tomorrow at 23:59 UTC.
* PulseAudio flat volumes * What is the plan for volume control viz.: (a) application developers (b) system UI components (c) end users * Is it reasonable to stick with disabling flat volumes for now?
* Default application changes * http://ur1.ca/omz06 [1] * Evolution, Boxes not yet resolved * Others seem noncontroversial, but open floor for these too
= = = [1] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Mon, 2016-03-14 at 17:04 -0400, Paul W. Frields wrote:
The Workstation WG meeting is scheduled for this Wednesday, 2016-Mar-16 at 1400 UTC (10:00 EDT, 15:00 CET). This agenda is open for additions/corrections; please send by tomorrow at 23:59 UTC.
- PulseAudio flat volumes
* What is the plan for volume control viz.: (a) application developers (b) system UI components (c) end users * Is it reasonable to stick with disabling flat volumes for now?
- Default application changes
* http://ur1.ca/omz06 [1] * Evolution, Boxes not yet resolved * Others seem noncontroversial, but open floor for these too
I'll drop my proposal to remove Evolution as nobody was enthusiastic about it; I'm still not convinced we need a mail client, but it seems safest to keep it. And it seems there has already been some good progress on the most important Boxes bug, so I think we can leave it be for now and reevaluate for F25. So maybe we don't need to discuss.
Michael
On Mon, 2016-03-14 at 17:04 -0400, Paul W. Frields wrote:
The Workstation WG meeting is scheduled for this Wednesday, 2016-Mar-16 at 1400 UTC (10:00 EDT, 15:00 CET). This agenda is open for additions/corrections; please send by tomorrow at 23:59 UTC.
- PulseAudio flat volumes
* What is the plan for volume control viz.: (a) application developers (b) system UI components (c) end users * Is it reasonable to stick with disabling flat volumes for now?
- Default application changes
* http://ur1.ca/omz06 [1] * Evolution, Boxes not yet resolved * Others seem noncontroversial, but open floor for these too
Here's a proposal from me:
Suggested F25 change: add an ostree-based workstation variant
We've started various aspects of the work required for it, so we should make this an official goal and put together a page to coordinate it.
On 15 March 2016 at 15:04, Matthias Clasen mclasen@redhat.com wrote:
We've started various aspects of the work required for it, so we should make this an official goal and put together a page to coordinate it.
We already have most of the parts required in gnome-software to install xdg-apps on top of an atomic image, we just need to finish how to update the base atomic image itself (which cockpit has already worked out).
Richard.
On Tue, Mar 15, 2016 at 11:04:28AM -0400, Matthias Clasen wrote:
Here's a proposal from me: Suggested F25 change: add an ostree-based workstation variant We've started various aspects of the work required for it, so we should make this an official goal and put together a page to coordinate it.
I have a few questions...
* What is the advantage to users of having such a variant?
* Are there behind-the-scenes advantages (as with Wayland)?
* Is it expected that all software will be installed via xdg-app? - including some of the base applications? - if so, can we be ready for the release engineering changes required for F25? - if not, what _is_ the mechanism for installing applications? - and does having applications installed in some non-container mechanism negate the advantages above?
And, also, you know my perennial question here: can we bring this into greater alignment with Atomic so that we a) have a unified story for users and developers and b) aren't splitting our resources?
On Tue, Mar 15, 2016 at 3:44 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Mar 15, 2016 at 11:04:28AM -0400, Matthias Clasen wrote:
Here's a proposal from me: Suggested F25 change: add an ostree-based workstation variant We've started various aspects of the work required for it, so we should make this an official goal and put together a page to coordinate it.
I have a few questions...
What is the advantage to users of having such a variant?
Are there behind-the-scenes advantages (as with Wayland)?
Is it expected that all software will be installed via xdg-app?
- including some of the base applications?
How do we distribute xdg-apps, are they going to be built as part of the Fedora process, and if not how does this align with the Fedora builds everything that ships with the Fedora label.
- if so, can we be ready for the release engineering changes required for F25?
This will need a lot of engagement from rel-eng.
On Tue, 2016-03-15 at 11:44 -0400, Matthew Miller wrote:
On Tue, Mar 15, 2016 at 11:04:28AM -0400, Matthias Clasen wrote:
Here's a proposal from me: Suggested F25 change: add an ostree-based workstation variant We've started various aspects of the work required for it, so we should make this an official goal and put together a page to coordinate it.
I have a few questions...
What is the advantage to users of having such a variant?
Are there behind-the-scenes advantages (as with Wayland)?
Is it expected that all software will be installed via xdg-app?
- including some of the base applications? - if so, can we be ready for the release engineering changes required for F25? - if not, what _is_ the mechanism for installing applications? - and does having applications installed in some non-container mechanism negate the advantages above?
And, also, you know my perennial question here: can we bring this into greater alignment with Atomic so that we a) have a unified story for users and developers and b) aren't splitting our resources?
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
has some answers to your questions.
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.
On Tue, Mar 15, 2016 at 12:30:18PM -0400, Matthias Clasen wrote:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation has some answers to your questions.
It does, thanks. I did look at that before but had forgotten some of it -- and it's a really nicely done document, so that's on me. Thanks for the reminder.
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.
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.
On Tue, 2016-03-15 at 14:11 -0400, Matthew Miller wrote:
On Tue, Mar 15, 2016 at 12:30:18PM -0400, Matthias Clasen wrote:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation has some answers to your questions.
It does, thanks. I did look at that before but had forgotten some of it -- and it's a really nicely done document, so that's on me. Thanks for the reminder.
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.
I hope my initial mail did not give the impression that 'we have it all perfectly planned out and all the work is done, lets just ask for the rubberstamp'. Figuring out all the required pieces and collecting them on a Change page is supposed to be the result of discussing this in the WG, not the input to that discussion...
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.
Of course, thats why there is 'ostree' in the subject line of the initial email. We are planning on using rpm-ostree and the regular Workstation content rpms for this (in fact, David King is already prototyping this).
On Tue, Mar 15, 2016 at 02:26:23PM -0400, Matthias Clasen wrote:
I hope my initial mail did not give the impression that 'we have it all perfectly planned out and all the work is done, lets just ask for the rubberstamp'. Figuring out all the required pieces and collecting them on a Change page is supposed to be the result of discussing this in the WG, not the input to that discussion...
No, I didn't have that impression either -- sorry if it sounded like I did. I'm just worried about a F25 target, because the F25 priorities in https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline are already _quite_ crowded.
I'm not against ambitious goals, I just want to make sure we're not set up for disappointment and frustration.
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
<snip>
We basically need:
* A central registry for xdg-app repositories As of now that registry is the fedora-workstation-repositories rpm packaged with Workstation. If we want this as a kind of web service or similar later that is another question.
* 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. <snip> This was done on purpose as I wanted the general policy to allow different editions and spins to develop their own policies. In Workstation we might want to make a rule that any application can at most have 3 versions - a nightly, a standard and a LTS version - for instance. (this is an example not a concrete proposal from me :)
While a spin might be perfectly happy to have Software display 50 versions of a given app or only want to allow GPL licensed applications for instance. Or only applications written using Java or whatever the goal of said spin is.
Christian
On Wed, Mar 16, 2016 at 04:58:55PM -0400, Owen Taylor wrote:
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.
*nod*
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
We have a big existing community which works to provide applications in Fedora as RPMs. Rather than making this basically be "thanks for all that but we don't need you anymore because it's all third-party with xdg-app", I hope we can bring those contributors in and along.
And, I think we're very likely to need more than just bootstrap, for two reasons.
First, the existing packaging model includes ongoing ownership and responsibility, and for all the warts that has, I think it'd be a big step backwards in Fedora quality and the trust users put in us to drop that.
And second, while I hope that we can achieve World Domination™ with this, convincing all application developers and upstreams is not going to be instant.
Maybe I'm just reading too much into the word "bootstrap". In any case, I think this needs to be high priority and invested in for this to succeed, rather than a "perhaps".
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.
The release engineering complexity is on the backend (and, yes, very real). The target here is the Fedora contributor community, and the goal is that applications could be packaged for xdg-app using dist-git (ideally, future dist-git with pagure), built with fedpkg, and fed to automated tests with taskotron, and released for testing feedback with bodhi.
That's some complexity, but it's also functionality that we'd want to duplicate somehow or somewhere _anyway_, and I think there's huge value in using a familiar workflow.
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...
I definitely agree on these points. I'm not sure it's a complete list, though. For example, I think "uses Nulecule" would be valuable, too. (And if Nulecule needs to be extended to cover desktop needs, we should get the people working on xdg-app involved in extending it.)
On Thu, Mar 17, 2016 at 10:14:20AM -0400, Matthew Miller wrote:
That's some complexity, but it's also functionality that we'd want to duplicate somehow or somewhere _anyway_, and I think there's huge value in using a familiar workflow.
[...]
though. For example, I think "uses Nulecule" would be valuable, too. (And if Nulecule needs to be extended to cover desktop needs, we should get the people working on xdg-app involved in extending it.)
And not just Fedora — it'd be great if the CentOS Container Pipeline could be used, as well. See https://github.com/kbsingh/cccp-index
On Wed, 2016-03-16 at 16:58 -0400, Owen Taylor wrote:
On Tue, 2016-03-15 at 14:11 -0400, Matthew Miller wrote:
We basically need:
* A central registry for xdg-app repositories
Central as in a webpage with a table, or central as in something that xdg-app is aware of and automatically uses?
* Perhaps a "bootstrap" repository where we make existing Fedora applications available as xdg-apps
Yeah, I think this is definately needed, because initially there is not going to be a lot of upstream supported xdg-app releases.
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.
In fact, xdg-app already does this as /run/host/fonts and /run/hosts/user-fonts. All you need to do is set up the right config for fontconfig in the runtime (and the gnome/fd.o runtimes already do this).
That is not solving the issue though, because how can you unstall into /usr/share/fonts if its a readonly ostree tree?
On Thu, 2016-03-17 at 16:42 +0100, Alexander Larsson wrote:
On Wed, 2016-03-16 at 16:58 -0400, Owen Taylor wrote:
On Tue, 2016-03-15 at 14:11 -0400, Matthew Miller wrote:
We basically need:
* A central registry for xdg-app repositories
Central as in a webpage with a table, or central as in something that xdg-app is aware of and automatically uses?
I mean specifically whatever determines what applications show up in GNOME Software. Whether that is supported in the xdg-app core or something that is layered over the top, whether it's a web service or a config file in an RPM - we need to figure that 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.
In fact, xdg-app already does this as /run/host/fonts and /run/hosts/user-fonts. All you need to do is set up the right config for fontconfig in the runtime (and the gnome/fd.o runtimes already do this).
That is not solving the issue though, because how can you unstall into /usr/share/fonts if its a readonly ostree tree?
It solves the problem if you are willing to define font installation as a per-user thing. We could have a /var/lib/fonts for system-wide installation and just say that you install fonts by dropping them there.
You won't share fontconfig caches between users or even between apps, but that's already an issue with /usr/share/fonts as you are mounting them.
- Owen
We've now started to put a change page together here:
https://fedoraproject.org/wiki/Changes/WorkstationOstree
Note that this is still very much a draft, and meant as input to the working group meeting in 2 weeks.
On 03/15/2016 12:30 PM, Matthias Clasen wrote:
On Tue, 2016-03-15 at 11:44 -0400, Matthew Miller wrote:
On Tue, Mar 15, 2016 at 11:04:28AM -0400, Matthias Clasen wrote:
Here's a proposal from me: Suggested F25 change: add an ostree-based workstation variant We've started various aspects of the work required for it, so we should make this an official goal and put together a page to coordinate it.
I have a few questions...
What is the advantage to users of having such a variant?
Are there behind-the-scenes advantages (as with Wayland)?
Is it expected that all software will be installed via xdg-app?
- including some of the base applications?
- if so, can we be ready for the release engineering changes required for F25?
- if not, what _is_ the mechanism for installing applications?
- and does having applications installed in some non-container mechanism negate the advantages above?
And, also, you know my perennial question here: can we bring this into greater alignment with Atomic so that we a) have a unified story for users and developers and b) aren't splitting our resources?
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
has some answers to your questions.
"The basic question with using Vagrant from a marketing perspective: how are we a better development environment for deployment on Linux if developers are working the same way they would on a different operating system."
I'd just like to chime in that exceeding the competition is ideal, but let's be careful not to lose ground by continuing to deliver an inferior experience while we decide what a perfect one is.
Right now, Vagrant gives Windows and Mac users an ability to continue working in an environment they're comfortable with while still being able to deploy on Linux. At least having this remain a highly-supported option means one fewer thing they have to learn in order to make the switch. So I guess what I'm saying is basically: don't fixate on having EVERY aspect of Workstation be a "better" experience. Wherever possible, let the day-to-day workflow remain the same for someone who is crossing over and then wow them with the ecosystem around it.
Remember: no matter how good the new workflow is, if it is *different* then users will complain and fear it (or irrationally complain without giving it a chance). Sometimes a slightly more polished solution that still works how people are accustomed will go further than a brand new solution that people are unwilling to try.
On Tue, 2016-03-15 at 14:44 -0400, Stephen Gallagher wrote:
"The basic question with using Vagrant from a marketing perspective: how are we a better development environment for deployment on Linux if developers are working the same way they would on a different operating system."
I'd just like to chime in that exceeding the competition is ideal, but let's be careful not to lose ground by continuing to deliver an inferior experience while we decide what a perfect one is.
Right now, Vagrant gives Windows and Mac users an ability to continue working in an environment they're comfortable with while still being able to deploy on Linux. At least having this remain a highly-supported option means one fewer thing they have to learn in order to make the switch. So I guess what I'm saying is basically: don't fixate on having EVERY aspect of Workstation be a "better" experience. Wherever possible, let the day-to-day workflow remain the same for someone who is crossing over and then wow them with the ecosystem around it.
Remember: no matter how good the new workflow is, if it is *different* then users will complain and fear it (or irrationally complain without giving it a chance). Sometimes a slightly more polished solution that still works how people are accustomed will go further than a brand new solution that people are unwilling to try.
Certainly having vagrant just work as well as possible is something that we need to have available, though if someone is happily firing up Ubuntu virtual machines from the OS X terminal, converting that person to do exactly the same thing on Fedora Workstation seems neither all that likely nor all that interesting.
(The fact that Vagrant boxes and some Vagrantfile options are tied to the provider is problematical. Providing an integrated out-of- the-box Fedora Vagrant experience relies on defaulting to the libvirt provider, but people coming from Windows and OS X will be depending on the virtualbox provider at least in shallow ways)
But what are the enhancements we could do to make using Vagrant in Fedora slicker and better? Should boxes be explicitly vagrant-aware, and present appropriate options for vagrant machines? Should we have some terminal integration to open up a new tab with 'vagrant ssh' to the vagrant machine running in the current working directory?
and if vagrant is being used "behind the scenes" to run testing instances of atomic apps (say) then we should be thinking at that higher level and how do we make *that* the good experience - the vagrant machine itself isn't very interesting
- Owen
On Thu, Mar 17, 2016 at 09:40:33AM -0400, Owen Taylor wrote:
Fedora slicker and better? Should boxes be explicitly vagrant-aware, and present appropriate options for vagrant machines? Should we have some terminal integration to open up a new tab with 'vagrant ssh' to the vagrant machine running in the current working directory?
Yes, that sounds awesome.
It would also be nice to have this not just be vagrant. In fact, in an ostree-based system, maybe it makes sense for the _default_ in GNOME Terminal to bring up a persistent utility container, and have bring up a host namespace shell as a secondary option.
desktop@lists.fedoraproject.org