desktop July 2014

desktop@lists.fedoraproject.org

40 participants
21 discussions

Proposed generic release criterion: service manipulation
by Adam Williamson 12 Jul '14

12 Jul '14

Still working on Fedora 21 release criteria. It seems to me that there's one area currently lacking in the criteria which all the Products would probably like us to have, hence I'm proposing it as a new 'generic' criterion, not Product-specific. We still haven't figured out exactly how to present the criteria, so for now I'm proposing this one be added as a new Fedora 21 Alpha criterion, i.e. it goes to https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria (under "Post-install requirements"). Here's the proposed criterion: System service manipulation It must be possible to start, stop, enable and disable system services using the initialization framework's standard commands. I don't think it needs any footnotes beyond standard 'References'. Does this seem reasonable to everyone? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 5

Re: 2014-07-09 @ **17:00 UTC** - F21 Blocker Review #1
by Bruno Wolff III 09 Jul '14

09 Jul '14

On Wed, Jul 09, 2014 at 23:07:12 +0400, Igor Gnatenko <ignatenkobrain(a)fedoraproject.org> wrote: >Hi, >On Wed, Jul 9, 2014 at 4:20 AM, Mike Ruckman <roshi(a)fedoraproject.org> wrote: >> # F21 Blocker Review meeting #1 >> # Date: 2014-07-09 >> # Time: 17:00 UTC (13:00 EST, 10:00 PST) >> # Location: #fedora-blocker-review on irc.freenode.neteria >> ... >> == >> // Mike >> Fedora QA >> irc: roshi | twitter: roshi_fedora >> blog: roshi.fedorapeople.org >Why this msg not going to the test-announce@? :P I don't think the meeting log needs to go to test-announce. If the complaint is really about the meeting notice, then that is arguably a reasonable suggestion.

1 0

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

Draft combined Alpha release criteria for F21
by Adam Williamson 07 Jul '14

07 Jul '14

Hi, folks. So I've just slapped together the existing release criteria drafts into a draft combined Fedora 21 Alpha release criteria page: https://fedoraproject.org/wiki/User:Adamwill/Draft_F21_Alpha_criteria product-specific notes: Cloud - AFAICS the Cloud-specific draft Roshi did only took things away, it didn't add any, so there is basically no change as far as Cloud is concerned. The wirding should exempt Cloud from all inappropriate criteria - please point out anywhere this is not the case. Workstation - none of the proposed new criteria are Alpha criteria. The Alpha proposals for a separate Workstation criteria page were simplifications of the more 'generic' criteria that apply to multiple desktops. There appears to be considerable confusion over an important desktop-ish question for F21, namely: "Are network installs of GNOME/Workstation and/or KDE considered to be release-blocking?" That is, do we only block on the Workstation (product) and KDE (spin) live images, or are we also going to block on network installation of either or both? As this has not been established, I have mostly left the desktop-y criteria and preamble wording as-is, with the intent that we can fudge it in the interpretation. If we decide that we do not block on desktop network installs, we can refine and focus the wording somewhat; if we decide to block on them, I'll have to insert something into the preamble and possibly fiddling with the 'release-blocking desktop' wording a bit to clarify precisely what we're talking about. This particularly affects the desktop criteria (obviously) and the "Package sets" criterion, which looks distinctly wobbly and would be a complete dead letter if we only care about the live images. I also just remembered that Workstation apparently wants to make it possible to install KDE as an alternative desktop post-install, which is...another fun thing to think about? Goddamnit, this is becoming a real PITA. Server - I plucked out the criteria that seemed most Alpha-y and inserted them into this draft in appropriate places, basically. You'll note that Server alone has a Product-specific section, down the bottom. A couple of the criteria proposed for Server and/or Workstation actually work okay as 'generic' criteria, so I added those into the generic section: those would be "SELinux configuration" (SELinux must be enforcing after installation - all Products want this, I believe) and "Scripted user creation" (which is primarily for Server, but since there's only one installer, it's probably fine for it to go in the generic installer criteria). I tweaked the "DVD package source" criterion to not refer to a now-obsolete deliverable - it talks more generically about a "dedicated installer image that contains packages". As things stand, I believe the only such release-blocking medium will be the Server image that contains server role packages (once we actually, you know, make that, but it's listed in the Server tech spec). I included the latest draft of my proposed "system service manipulation" criterion, since this is still a draft and it seemed best to get all the proposals in one place together. I updated the definition of 'release-blocking images' in the preamble to be appropriate for Fedora.next: "The current set of release-blocking images includes the images defined by the three primary Products - Server, Workstation and Cloud - in their product requirement documents and/or technical specifications, and the KDE live image." (I could make that a lot damn cleaner if all the Products defined their deliverables in the same document, btw :> some do it in PRD, some in tech spec. Actually, we *still* ought to have a deliverables policy. That's been on my todo list for, er, three years? Patches welcome. It's not actually a QA job.) There are probably still some corners of this that don't entirely make sense any more, please point out any logic fails etc. But I think it's probably at least better than the current page - https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria , which is completely un-Next-ified - as a basis for Alpha testing, which I once again remind folks, is supposed to start tomorrow :) So I'd like to get this into 'production' before Alpha TC1 drops. Next steps are going to be to write a couple more missing test cases, and come up with a vaguely plausible set of test matrices. I'll try and get that done this afternoon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Re: Proposed generic release criterion: service manipulation
by Adam Williamson 07 Jul '14

07 Jul '14

On Mon, 2014-07-07 at 11:50 -0400, Richard Ryniker wrote: > > It must be possible to start, stop, enable and disable system > > services using the initialization framework's standard commands. > > This sounds like any service that fails (will not start, will not > stop...) will block a release. You're the second person to read it that way, so clearly I wrote it wrong, but no, that is not the intention at all. > Should there be a distinction between "critical" services that must work > or block release, and lesser services that may fail and not block > release? For example, journald might be deemed critical, while sheepdog > is not. The intention is that the *mechanism* for manipulating services - that is, at present, systemd - works to the extent specified. The criterion assumes the notional service being manipulated is functional. In my head, if I'd actually been writing the criterion you thought I was, I'd have written something like "all system services in Fedora packages" or "all system services on the release-blocking media" or something like that - tied it to a *concrete* set of service scripts, not the entirely abstract notion of "system services" that's in the current language. Anyway, as I said, when two people read something wrong, I generally figure I wrote it wrong, so - can anyone suggest wording that would make this clearer? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Re: Proposed generic release criterion: service manipulation
by Adam Williamson 07 Jul '14

07 Jul '14

On Mon, 2014-07-07 at 10:45 -0400, Miloslav Trmač wrote: > ----- Original Message ----- > > On 07/04/2014 03:22 PM, Adam Williamson wrote: > > > System service manipulation > > > > > > It must be possible to start, stop, enable and disable system > > > services using the initialization framework's standard commands. > > > > > > I don't think it needs any footnotes beyond standard 'References'. > > > > > > Does this seem reasonable to everyone? Thanks! > > > > Is this another way of saying "All services must provide a systemd > > unit file"? No. > Same question here. I’ve never heard of an “initialization framework” > before, I'd guess that’s the piece of code and conventions to > run .ctors. Just saying systemd would simplify things (though, > perhaps s/must provide/must be controlled by/ ?) As mitr (I think) understands, the criterion is intended to test systemd. I said "initialization framework" because I have a pathological attachment to generics, I guess. :P I meant it to be read as a generic term for 'sysvinit, or systemd, or whatever we invent in five years to replace systemd', so I don't have to rewrite the release criterion then. If someone can think of a more commonly understood generic term, I'm happy to substitute that. We *could* just say systemd, if everyone promises to let me say "I told you so!" when someone notices in five years it still says 'systemd' even though we all switched to openrc or something. (har, har.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Workstation release criteria draft, pt. 2 (with bonus test cases and matrix!)
by Adam Williamson 04 Jul '14

04 Jul '14

I've now extended the draft Workstation release criteria to cover the functionality from the technical specification that seemed most to be things that ought to be a part of the criteria. Here's the current draft: https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_release_crit… and here's the diff from where it was yesterday: https://fedoraproject.org/w/index.php?title=User%3AAdamwill% 2FDraft_workstation_release_criteria&diff=381262&oldid=380627 broadly, I added criteria requiring the 'core' applications listed in the spec to be present at Beta time (they would not actually be required to *work* at Beta time, but they would be required to work at Final); requiring printing to work at Final; and requiring theming to be consistent between supported toolkits at Final. I wrote test cases for these criteria: https://fedoraproject.org/wiki/QA:Testcase_desktop_printing_local https://fedoraproject.org/wiki/QA:Testcase_workstation_core_applications https://fedoraproject.org/wiki/QA:Testcase_workstation_theming they're pretty simple so I didn't bother making them drafts, but of course they can be adjusted as needed. I also VERY quickly threw together (I am really rushing this, and honestly kind of sad that no-one has offered any kind of help in this area, despite the Fedora 21 Test Plan specifying that WGs were jointly responsible for this work...) a validation matrix template page for Workstation, modified from the existing Desktop validation matrix: https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_validation_m… I have notes of four other areas where criteria may potentially be desired: VPN firewall abrt IPA/AD do we want to have release criteria for some, all or none of those? i.e. do we consider specific behaviour in any of those areas to be of sufficient importance that we should block Alpha, Beta or Final releases on it? thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

Default application handling external USB devices changed to "Disk analyser"?
by Ankur Sinha 03 Jul '14

03 Jul '14

Hi, Has the default application that handles USB pluggable devices been changed to "Disk analyser"? It used to be nautilus iirc. When I used to plug my devices in, I used to generally get a "Open with Files" notification. Now I get "Open with Disk Analyser." I'm not sure why I'd like to open my device with "Disk Analyser" by default - I'd like to use the device, not see its properties, most of the time. Another thing - is it possible to choose an application from the notification, or can one just use the application that is being suggested? -- 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

Re: Default application handling external USB devices changed to "Disk analyser"?
by Philip Whitehouse 03 Jul '14

03 Jul '14

This seems to suggest both options are available, at least in a previous version of Gnome 3. http://unix.stackexchange.com/questions/17660/default-applications-gnome-3 As to why its changed, I assume the RPM upgrade script for Disk Analyser did this. It probably shouldn't. When I upgrade to Gnome 13 this evening I'll see if I can reproduce this issue. Sent from my HTC ----- Reply message ----- From: "Ankur Sinha" <sanjay.ankur(a)gmail.com> To: "Discussions about development for the Fedora desktop" <desktop(a)lists.fedoraproject.org> Subject: Default application handling external USB devices changed to "Disk analyser"? Date: Thu, Jul 3, 2014 08:32 Hi, Has the default application that handles USB pluggable devices been changed to "Disk analyser"? It used to be nautilus iirc. When I used to plug my devices in, I used to generally get a "Open with Files" notification. Now I get "Open with Disk Analyser." I'm not sure why I'd like to open my device with "Disk Analyser" by default - I'd like to use the device, not see its properties, most of the time. Another thing - is it possible to choose an application from the notification, or can one just use the application that is being suggested? -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

1 0

Should gtkhtml be on the copr repository?
by Ankur Sinha 01 Jul '14

01 Jul '14

Hi guys, Should gtkhtml be included in the copr? I don't see it there at the moment: http://copr-be.cloud.fedoraproject.org/results/rhughes/f20-gnome-3-14/fedor… The Fedora 20 version is 4.6.6-2 while rawhide/F21 is tracking 4.8.2 now[1]. Apparently there are bugs in gtkhtml that affect evolution. For example, this is one that I ran into with gnome 3.13: https://bugzilla.gnome.org/show_bug.cgi?id=732499 [1] https://apps.fedoraproject.org/packages/gtkhtml3/builds/ -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop July 2014