desktop February 2014

desktop@lists.fedoraproject.org

60 participants
46 discussions

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Adam Williamson 24 Feb '14

24 Feb '14

On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: > Installer is still a hot topic, but thats nothing we could resolve > during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? To give a bit of background and detail in QA's interest: First, to ensure everyone actually knows what we're talking about, we tend to talk about two major partitioning 'paths' in anaconda: 'guided' and 'custom'. 'custom' may also be referred to as 'manual'. In both newUI and oldUI, 'guided' is simply what you get if you don't pick custom partitioning, when you are given the opportunity to do so. In oldUI, you had the screen which gave you about five choices of different partitioning 'approaches' (reformat the entire disk(s), reformat only the Linux partitions, resize existing partitions to create free space, just install into free space, maybe one or two others I forgot). In newUI there's a different workflow after you pick target disks on the Installation Destination spoke which, broadly, accomplishes the same options in a rather different way. Broadly, QA is interested in doing something similar to what desktop wants to do, for slightly different reasons. Historically, QA and anaconda more or less agreed on an approach whereby the 'guided' partitioning path would be expected to work extremely reliably: QA would undertake to test every (well, nearly every) route through that path regularly and proactively, and anaconda would undertake to fix the bugs. Custom partitioning was much more of a 'bonus' thing: if it worked, great. QA would test it as much as we had time for, and anaconda would fix as many bugs as they could after fixing higher priority stuff. I went back and looked at the history, and in the earlier days of Fedora, the guided path was consciously designed to be very 'choice free'. Later in the 'oldUI' days, the path to more complexity in the 'guided' path was opened up by a sort of hack. Some people did not want LVM (after it was made default waaaaay back in FC3 or something), and eventually this demand became so persistent that it was decided to stick a checkbox in the 'guided' partitioning path which let you get a plain ext(3/4) layout instead of an LVM layout. This was always a kind of ugly compromise, it wasn't intended to be a design decision. It was manageable, because a plain ext3/4 layout is a fairly simple thing that isn't likely to break much. This context was kind of lost in the newUI re-design, and the 'I don't want LVM' checkbox kind of got a promotion. It's not a very good UI, and the point of the newUI stuff was to make the UI better, so instead of this 'special' checkbox, newUI used a dropdown menu - and because we were all ra-ra for btrfs at the time and expecting it to be the default Real Soon Now, and we thought we should make it easy for people to test the thing that was soon going to be the default, it got btrfs added. So in F18 we had a dropdown with "LVM", "ext4" and "btrfs" choices (IIRC). With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. By F20 we'd really kind of lost track of the initial intent, so no-one (including QA) really worried much about adding LVM thinp to the drop-down - it's a drop-down! it's for choices! - and now, we've got *four* major choices on the path that was originally supposed to be very dependable and choice-free and testable and maintainable, and of course we wound up shipping one of them entirely broken out of the box. QA and anaconda have already discussed this and, I think, we came to a tentative agreement that we could look at at least reducing the level of choice in 'non-custom' partitioning, and remembering the original intent we had (which I think both QA and anaconda teams quite like). It may be difficult to entirely drop the selection, but it seems at least reasonable to go back to only having one 'plain partition' choice and one 'LVM' choice (whether it's 'regular' LVM or thinp LVM), and relegating other choices to the 'custom' path. QA's angle on this is that it's really extremely difficult to develop a plausible set of storage release criteria and validation tests with the current situation. If we map out all the possible paths through the 'non-custom' path it still comes out to something like 80, given the current level of choice, and it's pretty impractical to test 80 different routes at every TC/RC build. Or even at every milestone. So if we don't change the design, QA is effectively forced to test only a reduced subset of the 'non-custom' path choices, whether we *plan* to do that or we pretend we're going to test them all but, inevitably, don't. Yet the installer design doesn't really communicate in any way that some paths through 'non-custom' install are more tested/reliable than others. Anyhow, that's kind of where we left off back in December or January, and we probably really ought to get around to looking at this again - and, as I said, incorporating the perspectives of the different Product WGs and the question of variant anacondas (whether any of the Products actually wants one, and if so, whether that's actually viable) pretty soon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

5 4

Testing wayland with packages from the 3.12 COPR repo
by Ankur Sinha 24 Feb '14

24 Feb '14

Hi, Is this still how one tests wayland? http://gcampax.blogspot.com.au/2013/10/every-frame-matters.html I went to a virtual terminal and used the gnome-session command provided above, and nothing happened. I do have the required packages installed. Bits of journalctl that seem relevant: http://paste.fedoraproject.org/79697/ -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

2 1

Tech Spec, System Installer
by Chris Murphy 23 Feb '14

23 Feb '14

Re: Fedora Workstation Technical Specification, System Installer https://fedoraproject.org/wiki/Workstation/Technical_Specification#System_I… The first sentence defines a preference for a minimalist installer user experience, with a hard requirement for dual-boot preserve existing OS (Windows and OS X). The second sentence uses "classes of hardware that are expected in workstation-class machines" which includes multiple devices (two SSDs, two HDDs, one of each). Could the WG clarify the scope of these statements? Taking them very literally, I could propose: 1. Remove Manual/Custom partitioning path entirely. The Tech Spec doesn't specifically say only the default path should become minimalist. 2. Remove all partition scheme options from the Automatic/Guided path. Two options isn't the minimum possible, no option is. The existing Automatic/Guided path permits multiple device selection, and makes an assumption how to use them. [1] Keeping with the minimalist preference, this could still mean no Manual/Custom partitioning: by continuing to make current or revised assumptions, [2] with or without informing the user; or conditionally present a simple UI that enables the user to assist in resolving the ambiguity with a few options: raid0, raid1, and one cache option once one is considered stable. (i.e. not raid4, raid5 or raid6 or concat.) So is the WG's intent that Automatic/Guided is a recommended path that should simply work for all uses cases, implying the user doesn't really need to be bothered with making such obscure choices? Should Manual/Custom partitioning be removed, de-emphasized (maybe relocated to its own spoke from the hub), or remain essentially as-is in which case the minimalist intent applies specifically to the default Automatic/Guided path? Chris Murphy [1] What they get depends on the partition scheme chosen, but none of them cause either raid0 or raid1 to be created. Instead, the LVM and Btrfs options use linear/concat, and the Standard Partition scheme puts /home on one drive and everything else on the other. There's no indication to the user how the selected storage will be used. [2] Perhaps most users choosing multiple devices in this path think raid1 is being configured? We're already making an assumption now that's probably less correct than assuming either raid1 or raid0, so it's not any more or less correct to change the assumption to something else.

5 9

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Chris Murphy 22 Feb '14

22 Feb '14

On Feb 21, 2014, at 2:38 PM, John.Florian(a)dart.biz wrote: > That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes, What you're essentially suggesting is the necessary trade off between stability and features isn't being balanced, in your experience. I'd agree with that assessment. I've done hundreds of Windows installs and thousands of OS X installs and those installers never crash. Ever. Seriously never. You can throw the most bizarre crap at them, even a disk with 42 partitions of just linux and BSD and they don't crash. And what interaction time? It's point and install. There's nothing to interact with because there are no options. > However, when I have my admin hat on, I want flexibility. I don't find that a compelling argument for many reasons, not least of which is the tens of thousands of OS X and Windows admins who get few install time layout choices, and they seem quite content. And they don't even have a kickstart equivalent, so I think it's fair to say flexibility is served by kickstart. > However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. It only makes more work if I have to do an in place resize later on. Having LVM on those host makes that resizing oh so much simpler though, especially if additional drives are required. > > I feel much the same about the /home partitioning and wish there was an checkbox in anaconda for that. Having a separate /home partition is good practice, but I never use the feature because mine is on NFS, so it makes for lots of click work to get the auto layout, then remove the home. (I did learn accidentally with btrfs I can just ignore it and I've not lost any space on /.) > So yes, simplicity is good, unless it makes everything else harder later. Elsewhere the idea is that the OS installer actually just installs the OS successfully. After that comes such customizations that we are putting into the installer that really don't need to be in the installer. Post-install if I decide I want /home on NFS, if I want encrypted /home, if I want to buy another drive and put /home on raid1, what do I use? Not Anaconda, it's an install time specific tool. The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. Chris Murphy

2 2

The vision for the Fedora Workstation
by Christian Schaller 22 Feb '14

22 Feb '14

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

17 44

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Adam Williamson 21 Feb '14

21 Feb '14

On Fri, 2014-02-21 at 16:38 -0500, John.Florian(a)dart.biz wrote: > > With the best of intentions, we'd gone from a reluctant exception to the > > 'no choice' design to a dropdown which included two very different > > complex choices: LVM and btrfs. So now the installer path which was > > originally supposed to be minimal-choice, very robust and testable and > > fixable, had become rather a lot more complex. > > Everything should be made as simple as possible, but not simpler. I don't think that precept applies very well to this area. The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it. It's worth trying some other installers out, just to reset your expectations. Have you seen the level of flexibility you get from Ubuntu's interactive installer? Windows'? OS X's? > I > appreciate your QA angle here. Every condition in a code path leads to > exponential growth in testing. And development. This isn't just a QA problem. We do not have the development resources to commit to all this stuff working reliably every six months. > However, when I have my admin hat on, I > want flexibility. I love LVM for that reason. However, if I'm setting up > simple VMs whose backend storage resides in a LV, I have no need or desire > for LVM within the VM. Does it hurt you to get it, though? I do my VM installs with LVs. I don't really need them. But nothing explodes, and two hours later I forget all about it. In the end it's just bits. As long as the bits are where they need to be when things need to read them, who *gives* a monkey's tail? I did recognize that it would be tough sledding to get back to zero choice, and if you ask me to crystal ball it, we might have to wind up back at 'plain partitions or LVM'. But that's still a substantial improvement on where we are right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Technical spec for the workstation, second draft
by Matthias Clasen 21 Feb '14

21 Feb '14

Thanks for all the feedback ! Instead of replying individually, I've made a number of edits to the document, picking up some of the suggestions made in the discussion. In particular: - Added a preface explaining that some parts of the spec may not be 100% realized in the first version, and that the spec needs to be aligned with the base WG - Added gedit and nautilus as core application - Added an explanation of the term 'core application', and language to discourage dependencies between applications. - Added 'problem reporting' to core services - Reworded the firewall section - Added developer assistant as core application - Update the package list and sort it - Added a 'file system' section - Specify that the theme will be Adwaita - Added an (empty) section for installation methods and media Keep the feedback coming

1 0

Re: technical spec for the workstation up for review
by Jc 20 Feb '14

20 Feb '14

Christian Schaller <cschalle(a)redhat.com> wrote: > > > > >----- Original Message ----- >> From: "Bastien Nocera" <bnocera(a)redhat.com> >> To: "Discussions about development for the Fedora desktop" <desktop(a)lists.fedoraproject.org> >> Sent: Wednesday, February 19, 2014 6:40:37 PM >> Subject: Re: technical spec for the workstation up for review >> >> >> >> ----- Original Message ----- >> > Hi, >> > I ended up calling the firewalld maintainer to understand the state of >> > things >> > and there is this concept in firewalld called zones that we should be able >> > to >> > use to create a better user experience, yet at the same time keep the >> > firewall >> > working when people connect with their laptop at an internet cafe for >> > instance. >> >> Right. But firewalld can't a Fedora-only solution, otherwise no application >> developer >> will want to integrate with it. > >We don't need the application developer to intergrate with it. All we do is that >in the GNOME Shell/NetworkManager we ask a question the first time you connect to >a new network, something like 'Is this a trusted network?'. If the answer is yes >we put firewalld in trusted network mode for that network, and everytime the user connects >to that network afterwards we default to that trusted setting without asking again. >In this mode the firewall will let basically anything through. > >For untrusted networks like conference wifi or internet cafes people choose 'not trusted' >and we use the current firewalld default. > >These settings can then be toggled in the connection manager if you at any point want >a specific network to become trusted/untrusted. > >This model is very simply (just 2 modes) and it gives our users some extra security when >connecting their laptops in public places, including protecting them from themselves in >terms of accidentally sharing their private photos and videos on a public network. >It should also be quite unobtrusive. > > >Christian >-- >desktop mailing list >desktop(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/desktop

1 0

[Proposal for vote] GNOME as default base of the Workstation Product
by Josh Boyer 19 Feb '14

19 Feb '14

I'm calling for a vote on the default DE used as a base for the Workstation Product. The overall discussion seems to have played out, so let's get things settled. As the subject says, I'm proposing we use GNOME as the default base of the product. WG members have one week from today to vote or counter-propose. Missing votes after one week will be counted as abstains. PLEASE NOTE: I believe the WG would really like to see KDE be a release blocking alternative DE under the premise that we can work together with the KDE team and get consensus on the technical aspects of what Workstation should provide. However, I did not want to put two issues in the same vote before we've really had a chance to discuss those technical aspects, so the proposal is only for the default DE choice. We will vote on alternative DEs at a later time. Thanks! josh

15 16

So are we skipping a gnome release?
by Elad Alfassa 17 Feb '14

17 Feb '14

GNOME 3.12 is due to be released in March, but as I understood there won't be another Fedora release before August. So what's the plan? Are we going to skip GNOME 3.12 entirely? I would much rather if we could (for a lack of a better term) ignore the fedora package update guidelines and provide 3.12 for F20 when it's released. -- -Elad Alfassa.

12 23

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop February 2014