Re: The vision for the Fedora Workstation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



As Adam pointed out in his reply (I will respond to his email separately) I should have been clearer in using the term Fedora Workstation as opposed to the word Fedora, as a lot of the
things in my email of course applies specifically to the workstation and not to for instance the server or cloud product. Not sure boot.fedoraproject.org really fits under the Workstation heading.

As I said in the initial email the goal for the installer is to not be a tool for selecting packages, instead just focus on the bare minimum to get your system up and running with the defaults. Once you are up and running the Software installer will be the tool to use to customize.

As for Developer Assistant I think we will want to ship that as part of the default image, I also think that we should look into making Developer Assistant the installer for a lot of stuff developers might want, like sql databases and so on, things which is not a very natural fit in the general desktop software installer.

Christian



----- Original Message -----
> From: "Zoltan Hoppar" <hopparz@xxxxxxxxx>
> To: "Discussions about development for the Fedora desktop" <desktop@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, February 10, 2014 7:08:14 PM
> Subject: Re: The vision for the Fedora Workstation
> 
> Hi,
> 
> I have few question for now - would be possible that the smallest core will
> be the boot.fedoraproject.org as option, and as extended core a minimal
> system with gui and installer? Would be possible have preselections in the
> installer based on FAS, or after role? Eg. If I am an ambassador, or
> designer can I get the necessary preselected/preferred tools for it when I
> trigger install? With that we can unite all the spins, and no need them to
> store it separately, because possibly all will be just a selection list?
> 
> I think for the "500 devel tool" part I can say that we have already an
> awesome tool that can even help to set the complete environments A-Z maybe
> under the install process, it's called Developer Assistant. Really would be
> huge to have it as an option in a spoke maybe if somebody needs
> it/preselects it.
> 
> Thanks,
> 
> Zoltan
> 
> 
> 2014-02-10 18:40 GMT+01:00 Paul W. Frields < stickster@xxxxxxxxx > :
> 
> 
> 
> On Mon, Feb 10, 2014 at 09:48:08AM -0500, Christian Schaller wrote:
> > 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.
> 
> It was good to see folks at DevConf.cz from around the community.
> Many people took away from the conference an understanding that we
> need to communicate in more detail and more often. It really does
> help move the discussion forward. The Fedora.next and FESCo
> presentations and discussions were also helpful.
> 
> > 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'.
> 
> This is a key point that might have been missed or misunderstood
> earlier. Making it so that Qt apps look good and work well in GNOME 3
> would be a great end result.
> 
> > 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.
> 
> Would we want some sort of validation tool that helps users tell
> whether a system has been mangled? This could be important for BZ as
> well as community members that help others solve problems. Probably a
> detail, but could be a useful one to include in discussion.
> 
> > 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.
> 
> Agreed -- too early to tell, and the fact that containers are a hot
> item shouldn't block forward progress to define more of the detail of
> the Workstation.
> 
> > 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.
> 
> Thanks for doing this. I like a lot of what I see here and intend to
> participate in more discussions with the WG members.
> 
> --
> Paul W. Frields http://paul.frields.org/
> gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
> http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
> The open source story continues to grow: http://opensource.com
> --
> desktop mailing list
> desktop@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/desktop
> 
> 
> 
> --
> PGP: 06853DF7
> 
> --
> desktop mailing list
> desktop@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/desktop
-- 
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop





[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux