So as many of you might know the Devconf.cz conference was hosted in Brno this week and
there was quite a few Fedora related sessions there. It also gave me a good chance to
speak face to face with a lot of people from the Fedora community. One realization that I
made was that a lot of stuff I felt was clear to understand from the PRD actually
wasn't that clear to people. So being the primary author of the current PRD text I
thought it would be useful to lay out the vision in a bit more detail. Of course a lot of
these things will be hammered out in more detail in the technical specification, and the
technical specification will of course be the official description of the product as it
will be the version the working group discuss, tweak and finally put the formal stamp of
approval on. So please read this email as me laying out the vision of the PRD as I see it,
to try to clarify some issues, but be aware that the points in this email are not fully
fleshed out yet or gone through a proper working group review. So details might change.
1. The name is not important here, we might as well have called the product working group
the Desktop Working Group or the Client Working Group. The name workstation was chosen
mostly to emphasize that technical users are of importance to us. So please do not get
hung up on the name.
2. Is it using GNOME? Is GNOME the default desktop? Realistically speaking I think the
answer to the first half of the question is yes. This is the default in Fedora today, it
is where we have a large skilled team at Red Hat and thus it is the place we have the
ability to enact the most change. That said the answer to the second half is 'yes and
sorta no'. One of the goals of the PRD is to try create the idea of a 'Fedora
Desktop'. So yes, we will pull in GNOME 3 as the baseline for the Fedora Desktop, but
the definition of the 'Fedora Desktop' goes beyond that. For instance we will have
supported APIs and technologies in the Fedora Desktop that have nothing to do with GNOME.
For instance integrating Qt as a platform component is part of the plan here, despite Qt
not being a 'GNOME technology'. We are looking at integrating applications from
various Web platforms, like Firefox and Chrome apps, despite these not being 'GNOME
technologies'.
3. Will other desktops be blocked from the Workstation? No. First of all the plan as I see
it is that we will continue with both GNOME and KDE as release blocking as we do now. The
rest will continue being available to the degree that their respective teams are able to
keep providing them, like now. What will change is how you install those desktops and what
is expected of them. The general idea here is that the Workstation install will install a
small core package set onto your system. From there you can add what you need, including
desktop environments from the Software installer. There will be some requirements for how
these desktop environments operate, for instance they would need to make themselves
available through GDM and respect any settings that come to them from GDM. They can not
make changes to the system that will break the default Fedora Desktop session. And if one
of the non-blocking desktops fail to be ready for a given release then the user will get
dropped backed into the default session after upgrade, although we should if possible warn
them through the installer that this would be the result of them upgrading. If a desktop
is not interested in following these rules they will not be thrown out of the Fedora
package repository of course, but they will not appear in the UI installer and people will
have to get them from the command line.
4. Will I be able to install/de-install whatever I want? Yes and No. The system has a
default package set which is meant to be installed at any time for it to still be
considered the Workstation. This is part of the API we are offering to 3rd party devs. The
UI tools we provide will not offer the option of removing any of these core packages.
However the command line tools we have now are of course all still there, and using them
you can of course change your system to your hearts content, but of course this is a
option for the especially interested and just like you can't go to Volkswagen and
complain about how the old 79 Beetle that you put a Porsche 911 engine into is a danger to
drive, you can't come to Fedora and complain that your custom system has problems.
5. Since there is a developer focus will the ISO ship with 500 IDEs? No. We will work to
package and make as many tools available as we can of course, but the Software installer
is an integral part of the user experience here, and the idea is that you gets the tools
that you want and need through that. Pre-loading the system with 500 IDEs is a blunt and
unprecise tool that comes with a lot of downside, and it being seen as a solution is to me
more a symptom of not having a good Software installer than anything else.
6. Will the rules and policies of the Workstation be defined through implementation or
through specifications? Both approaches will be used. For some things we will use the
implementation path for others the specification path. So as mentioned above for the
display manager we will likely use the implementation part, but for things like the
planned API for container images we will likely use the specification path. The evaluation
of which option to choose will be based a lot of things, like if its a Fedora internal
solution or meant to be a solution beyond Fedora too. It will also depend on the amount of
work involved and the risks involved for the overall product. And if anyone wondered we
will keep systemd as our init system despite it not working on Hurd :)
7. Will the Workstation use containers instead of RPM? For the short to median term the
answer to this question is no. For the long term the answer is that most likely that we
will continue using RPMS to some degree. Container technologies will be developed and
matured over the next few years and the desktop working group will look to experiment with
them and use them where it makes sense, in collaboration with the other working groups.
Personally I don't see a 'pure' container based future as very likely, my
expectation is that we will keep using RPMS for the core and containers for at least part
of the application stack. I also expect that there is a good chance RPMS will be part of
the composition toolset for building container apps. But we are speculating about the
future here, so my general suggestion is that we will cross this bridge when we get to it,
as arguing about it now easily end up being an unproductive discussion about the
hypothetical features of the system we think the person we are discussing with has in his
or her mind.
I hope this answers some of what I have been told is a bit unclear to people. I held of
sending this email for quite a while simply because I felt it would preempt the work on
the technical specification, but I was repeatedly told that it would be better to remove
some misconceptions out there as quick as possible as long as I prefaced it with a
disclaimer that the working group of course still need to run its course and that the
final result of that work will not be a carbon copy of what I say here.
Christian