desktop May 2014

desktop@lists.stg.fedoraproject.org

31 participants
19 discussions

List of Qt/Qt5 packages for Fedora WS
by Lukáš Tinkl 29 Aug '14

29 Aug '14

Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation: qt qt-x11 qt-settings qt5-qtbase qt5-qtimageformats qt5-qtsvg qt5-qtx11extras qt5-qtxmlpatterns qt5-qtdeclarative qt5-qtquickcontrols qt5-qtdoc qt5-qtconnectivity qt5-qtmultimedia qt5-qtgraphicaleffects (you can see the dep chain of qt5 packages here: https://fedoraproject.org/wiki/KDE_updates) -- Lukáš Tinkl <ltinkl(a)redhat.com> Senior Software Engineer - KDE desktop team, Brno KDE developer <lukas(a)kde.org> Red Hat Inc. http://cz.redhat.com

35 104

Introduction, Documenting Workstation
by Pete Travis 17 Jul '14

17 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm acquainted with many of you already, but an introduction seems fitting anyway. I've been involved with the project for a few years now, primarily on the Docs team but also some light packaging and lately light infrastructure things. I live in Montana, US, where the population density is almost as low as the temperature. I work for a small government agency doing user and systems support. Why should you care? Well, the Docs team reached a decision this last weekend to proactively work with the Product WGs to assess documentation needs. I volunteered to liaison with the Workstation team. As we approach the release cycle, I'd like everyone to keep documentation in mind and the discussion open about not only implementation, but how to represent that implementation to the users. An undocumented feature isn't featured :) I'm looking forward to working with everyone, perhaps saying hello at the next meeting - there are meetings, right? - and developing a presentation of the Workstation Product that shows off the capabilities and character of your work. - -- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNW1PAAoJEL1wZM0+jj2Zos4H/37WaPQMRumzi766cXv6x3mb ADJuFmZ+mZwosTynurCAKG5p8PczOHKhRrZNslf9nFNx4dczc94QJFlO7hPOq3Mr WOzkSn6pUXppukAd6UxX7qAjtrNomYCM8kDlmyK+ArZmVbo78O2IppeSwZk4R/tJ ILnktcYl4sXJjlOrA28X5uiZ0dvreuZPBT+UsiDZHVvFBQfaYqjUKIioW/R4wQYp FoFvLbXe2XCn609LuHl0TcEP9DIwd2ShKROqw2fhXXSPe4jWWwkm0+FktwEKAt46 DqKBpIZeeIIZfiKXRPS6CCGNOULboepDKj+7RfqmtrjUIqdPQZ4ZP+Hdr1vSC3M= =G3EO -----END PGP SIGNATURE-----

2 2

Workstation status and TODOs
by Josh Boyer 07 Jul '14

07 Jul '14

Hi All, We have just less than 3 months before the F21 Alpha change deadline comes. That means that now is the time to get going in earnest on making sure we have all the things we want lined up for the initial release of Workstation done. Matthias and Christian have done a great job of getting us started, and have gotten some major Changes approved. The GNOME 3.12 rebase was accepted, and the enabling of SCLs should go over fairly well once the questions are addressed. So what is left? Off the top of my head I can think of: 1) Getting the kickstart for Workstation cleaned up with the appropriate package lists (I'd be willing to get this rolling) 2) Integrating KDE into the above in whatever form we work out with the KDE team 3) KDE variant of Adwaita theme 4) Firewall/firewalld integration issues 5) Installation and compose methods work with rel-eng (live image default, but install tree necessary for compose. PXE/netboot iso? etc) I'm sure I'm missing a few things here. Please chime in with what I'm forgetting. In short, there's more than enough work to go around. Lastly, we've been rather quiet as a WG as of late. The Cloud WG is going through a confirmation process with their members to make sure people are still interested and willing to do work. That's not a bad idea for ourselves. WG members, please take the time to reply with whether or not you wish to remain a WG member. As an aside, much of the "heavy lifting" in terms of process is done for this release. The PRD and Tech Specs have been approved, and the initial round of Changes are submitted. Not being overly familiar with the underlying code in much of the DE stacks, my participation has been limited mostly to those kinds of process things. I think we still have some discussions to have on process and interactions with other groups, but I thought I would double check that the WG feels I'm doing a decent job representing them in this capacity. I'm happy to continue to pitch in where I can, but if the WG feels they'd be better served by someone else as the FESCo liaison, please speak up. josh

6 9

Desktop and FirewallD
by Christian Schaller 06 Jun '14

06 Jun '14

Hi everyone, So in response to the ongoing discussion about Firewall functionality and the desktop we had a call at the end of last week with some representatives from both the desktop and firewall development teams, trying to figure out a good compromise and a way forward. I hope people can take the time to look over the ideas we discussed and let us know if you think it is a workable solution. On the call was: Thomas Woerner Matthias Clasen Bastien Nocera Daniel Kopecek Jiri Popelka Peter Vrabec We had a wide ranging discussion going from what is doable in the Fedora 21 timeframe to what we want from a firewall solution in the long run, what the setup is like on other operating systems, the tradeoffs between security and usability, API and adoption, ease of sharing versus unintended sharing and different corner cases where the different models might break down a bit. We all agreed on the following core principles * We want users to be as secure as possible * We want users to have their privacy protected as well as possible * We want users to have a good experience using our products * We want users to be able to use services such as DLNA, Chromecast, Avahi and more without having to search on Google, and more often than not be told that the fix is to disable the firewall. * We all agree that there is no perfect solutions on offer here. Just a range of different tradeoffs. A system with a running firewall isn't secure nor is a system without a firewall insecure. Instead they exist on a continium of 'more secure' and 'less secure'. The challenges seen: * With the current default a lot of services don't work out of the box because the firewall silently blocks them * There doesn't seem to be any non-expensive way for the system to detect that a service is running and being blocked by the firwall. * There is very limited use of the firewalld API for doing things like port unlocking and similar due to it being a predominately Fedora and RHEL only solution currently * Some application developers who do look into using the current API find the API hard to use * The current NetworkManager UI to change zones is both maybe a bit hidden away and also the Zones options listed there are not intuitive or documented in the UI. Plans for Fedora 21 * The Desktop team will look into creating a UI that asks you when you connect to a new wireless network if you consider it trusted or not. Exact wording of the question and look of dialog etc. will need to be worked out. This setting will be remembered for that network. If user say trusted the zone used will be 'trusted', if not trusted then current default will be used. Should be simple enough to not confuse users, yet improve their security on public networks. * Other connection types will keep the current default which sucks a bit for your home ethernet, but we don't currently have a good way to identify your ethernet connection and popping up a dialog every time you connect is probably a worse user experience than having to google a bit. Matthias started a prototype of this already here: https://bugzilla.gnome.org/show_bug.cgi?id=727580 Long term plans * Work with NetworkManager team to see if we can come up with a way to identify ethernet connections in a similar manner * Look into proposing a new DBUS API for firewalld * We will keep talking to see if there are more granular approaches that can be developed as we go forward. For many cases the trusted/untrusted question is a bit to simple. For instance you probably trust your work network, but that doesn't mean you want to share your beach vacation photos on the office network. * Look into using the zones descriptions somehow in the NetworkManager Zone setting UI to make it a bit more understanable than just a list of names. FirewallD team will work on making the descriptions internationalizable. Matthias filed two bugs related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1091067 split off zone configuration in subpackages https://bugzilla.redhat.com/show_bug.cgi?id=1091068 overprotected api

7 6

Gnome 3.12 to Fedora20?
by Greg 04 Jun '14

04 Jun '14

since i cant find anything new on this topic. im gonna ask . when is 3.12 gonna be pushed to the Fedora repo's? or is it still in Discussion? if it is can someone point me to where i can follow the conversation about this please. thankyou

10 13

Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Adam Williamson 29 May '14

29 May '14

Hi, folks. So continuing with the theme of setting up the Fedora.next QA process, I thought before going too far with draft release criteria etc, we could discuss a couple of important points that have come up since I sent out the draft test plan. There are two kind of similar issues in particular I'm thinking of. First, at the QA meeting this week, tflink pointed out that we would need to decide whether we will have sort of 'parallel' blocker/freeze exception bug processes for each product. That is, do we have: F21FinalBlocker F21ServerFinalBlocker F21WorkstationFinalBlocker etc etc, and separate lists of blockers on http://qa.fedoraproject.org/blockerbugs/current per product (and non-Product-specific), and separate meetings? Or do we keep the 'unified' blocker nomination / review process, and just handle blocker bugs for all Products within it? At first blush I'd incline to keeping a single unified process, because splitting them up seems like an awful lot of work and I'm not sure it comes with a clear benefit. It also relies either on reporters correctly determining what product their bug is relevant to, or on a triage step for blocker nominations. However, it's worth noting that if we allow the release schedules for the Products to diverge in future, it would probably then be inevitable that we'd need split blocker review (and release validation, for that matter). Second, there's a similar issue of organization with regard to the release criteria. I haven't explicitly written this down anywhere, but I've been sort of unconsciously expecting that we'd keep the existing 'generic' release criteria pages for criteria that are not Product-specific, and then we'd have Product-specific release criteria pages which would basically be *additive*: they'd add additional criteria applicable only to that Product. They could also perhaps 'patch' the generic criteria to a limited degree, though this would get messy if the delta got too great. However, Mike (roshi) has produced draft release criteria for the Cloud product as part of his work on the 'test outline' for that product - https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Release… , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Release_… , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Release… - and used another possible approach; the criteria he has drawn up are clearly intended to be *comprehensive* with regard to the Cloud product. They would not need to be read in conjunction with the 'generic' criteria. I'm not as sure which approach I prefer here, and to a degree the difference between them isn't as clear cut as it appears at first glance; however the criteria are ultimately presented, we'll likely have several that are applicable to multiple Products. Even if these are displayed multiple times on 'comprehensive' pages for each Product, they might be shared at the 'source' level using mediawiki transclusion, for instance (to prevent them diverging unintentionally). And of course we aren't necessarily tied to mediawiki for presenting the criteria, which is another factor to bear in mind (I know one of tflink's Grand Plans involves a different way of maintaining and presenting the release criteria). Thoughts on the best approach for each of these issues would certainly be appreciated! I thought it'd be best to take some time to think them over before moving ahead with drafts and so on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 7

Re: Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Adam Williamson 28 May '14

28 May '14

On Wed, 2014-05-28 at 09:15 -0600, Mike Ruckman wrote: > I think we might be able to strike a balance here between total > separation and a unified blocker process (though it incurs a bit of > overhead). Just as we currently mark bugs as blockers, we can continue > to do that - but *also* mark them as F21<foo>FinalBlocker. This would > allow for tracking at the product level but also keep some sanity with > blocker meetings. Then, later down the road if the blocker process > diverges with each product, they can simply drop the generic blocker > tracking bug. > > I don't immediately see much of a downside to this - but then again, > that doesn't mean there isn't :) At the very least it might lessen the > learning curve as we carve a new path with Fedora.next. I thought of something similar, but just as a whiteboard field entry, to make it less intrusive. That should be enough metadata for searches. I should note that I was remiss in my original email in missing one issue with the 'combined' approach: it will likely require WG representatives to be present at most blocker meetings. I expect we'd at least want reps of any WG whose product is obviously affected by / involved in a given blocker to be present at the review meeting(s) for that blocker. For the last few releases, blocker meetings have become almost QA-only a lot of the time, or QA plus releng; we haven't had very good representation from devs/packagers. A 'softly softly' approach to improving that hasn't gone very well; I think outside of QA and releng, people have developed this mindset where the blocker review process is something that Just Sorta Happens in the background, and they only get involved where it touches upon them directly (e.g. they're actually assigned a bug that's nominated as a blocker). We're probably going to have to change that mindset in a .next world: we would already quite *like* the expertise and input of folks outside QA/releng to the blocker process, but in a world with Products with more domain-specific release criteria, we're really going to need it. > > Second, there's a similar issue of organization with regard to the > > release criteria. I haven't explicitly written this down anywhere, but > > I've been sort of unconsciously expecting that we'd keep the existing > > 'generic' release criteria pages for criteria that are not > > Product-specific, and then we'd have Product-specific release criteria > > pages which would basically be *additive*: they'd add additional > > criteria applicable only to that Product. They could also perhaps > > 'patch' the generic criteria to a limited degree, though this would > > get messy if the delta got too great. > > > > However, Mike (roshi) has produced draft release criteria for the > > Cloud product as part of his work on the 'test outline' for that > > product - > > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Release… , > > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Release_… , > > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Release… > > - and used another possible approach; the criteria he has drawn up > > are clearly intended to be *comprehensive* with regard to the Cloud > > product. They would not need to be read in conjunction with the > > 'generic' criteria. > > Just so we're clear here: I split out the cloud specific (from what I > could tell) criteria out so that it was easier for me to keep track of > in my head [0]. I wasn't intending it to be an end solution (even though > I suppose it could be, at some point). Sure, I understand that - but just the fact you did it this way highlighted that it was actually one possible 'final' approach. Before I saw your drafts I hadn't even really considered it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 2

Draft Fedora 21 Test Plan
by Adam Williamson 27 May '14

27 May '14

Hi, folks! So, I quickly bashed out that draft F21 Test Plan I've been threatening to write for the last month or so. https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan So, what's the idea here? Really, I'm just trying to come up with a starting point for all the decisions we need to make and planning we need to do for Fedora 21 testing, especially release validation testing, especially as regards Fedora.next. There's some mention of other stuff in there, but what I'm really trying to think about is what we need to do to extend our test processes to cover all the stuff that's coming as a part of .next. I think the most interesting points are these: * There are several practical implications from the test plan - just Work We Need To Do. Most obviously, we need to draw up release criteria and supporting test cases for the Fedora.next Products. We also will need to adjust the https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event SOP to include those cases/matrices as they're created, and adjust the https://fedoraproject.org/wiki/Release_criteria page to refer to/include the Product-specific release criteria as *they're* created. * Responsibilities! Particularly, in this *draft* Test Plan, I've suggested that creating the Product-specific criteria and test cases should be the responsibility of the relevant Working Groups, with assistance from the QA team. They would also be jointly responsible, along with the QA team, for conducting Product-specific testing, on the general principle that the more Product-specific a bit of testing is (and the more domain-specific expertise it needs), the more it's the WG's responsibility and the less it's QA's responsibility. Note that (again, as a suggestion in this draft) the QA team is still responsible for Fedora 21 testing *overall* - i.e. it's the QA team's responsibility to make sure the WGs do the stuff assigned to them in the plan. If that makes sense. Discussion welcome! * Feasibility. This is, of course, one I really want to nail down. It will require, though, that the Product-specific release criteria and test cases / matrices get written. Once we have those, we can try and make a realistic judgement as to whether we as a project - the QA team and the WGs - actually have the resources to complete the minimal necessary level of testing within the scope of the F21 schedule. If we don't think that's going to be the case, we can take that to FESCo, and we can decide what to do about it that way. In the meantime I've provided a *very* vague 'Required resources' section just to sort of flag this up in a modest way. I'd really, really appreciate feedback on this draft from all interested parties - QA folks, WG folks, FESCo, anyone at all reading this who has an opinion. Please, bikeshed away. It all helps. I'll aim to kick off discussion between the WGs and QA about creating Product-specific release criteria and test cases next week. Obviously that's *somewhat* subject to feedback on this very draft, but I can't really envisage a world in which we aren't going to need those two things to happen, and whoever's job we ultimately decide it is, I don't *think* that me just kicking off an attempt to draft them can be a bad thing. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 3

Fedora.next Product Branding
by Ryan Lerch 23 May '14

23 May '14

*This is sent with my Fedora Design Team hat on* With the creation of 3 products for Fedora, the Fedora Design Team anticipates manynewquestions aroundFedora'sbrand. As the main caretakers of the Fedora brand, weare going to have to figure these things out within the next few months. For example, the Design Team is starting to think about how to answer these types of questions: • Should each product have its own logo? or • Can you add our product to the Fedora website? or • Can you make our product its own website? (How should we represent these products on the website? Should we allow products to have their own separate websites?) To start off the rebranding discussion, the Fedora Design Teamhas4 basic questions for each of the 3 product-focused working groups to answer: (1) What problem does your product solve, in one sentence? (2) Who is the target audience for your product, in one sentence? (3) List at least 5 products that successfully target the same target audience you are after. (4) List at least 5 products that try to solve the same problem. We are reaching out to each group individually to ask that you discuss these questions and come back to us with answers by Wednesday, December 4th2013. cheers, ryanlerch

5 8

Your input is needed: Fedora workstation comps group
by Elad Alfassa 22 May '14

22 May '14

Hi all. As you may know, we need to create a comps group for Fedora Workstation. The comps file already has a comps group named "developer-workstation-environment", but it contains things that we might not want to put in the default Workstation environment. So, should we "take over" that group and change it to fit our needs, or create a new group? if we create a new group, what should we call it? should the comps group be named fedora-workstation, workstation, or something completely different? All I need is your input regarding naming here, I'll do all the boring part (adding it to comps and making sure we don't add any packages in the kickstart file). Thanks, -- -Elad Alfassa.

4 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop May 2014