kde December 2013

kde@lists.fedoraproject.org

25 participants
27 discussions

Onscreen keyboard vide
by Kyle 14 Dec '13

14 Dec '13

Hello, I created a video showing how slow/difficult it is for a disabled person (me) to type using an onscreen keyboard that is lacking. My hope is that the open source gurus will code something better. See link--->https://bugs.kde.org/show_bug.cgi?id=265452#c27 Any questions/comments let me know... Kyle -- *"I have no special talent. I am only passionately curious." - Albert Einstein* *"God must love the rich or he wouldn't divide so much among so few of them." --- H.L. Mencken *"So long as the universe had a beginning, we could suppose it had a creator. But if the universe is really completely self-contained, having no boundary or edge, it would have neither beginning nor end: it would simply be. What place, then, for a creator?" --- Stephen Hawking **

2 1

Re: Criterion revision proposal: KDE default applications
by Adam Williamson 13 Dec '13

13 Dec '13

On Fri, 2013-12-13 at 05:31 +0000, "Jóhann B. Guðmundsson" wrote: > On fös 13.des 2013 02:05, Adam Williamson wrote: > > It was clear at the Go/No-Go meeting today that KDE SIG does not > > consider this release criterion applicable/desired: > > > > "All applications that can be launched using the standard graphical > > mechanism of a release-blocking desktop after a default installation of > > that desktop must start successfully and withstand a basic functionality > > test." > > > > https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_app… > > > > jreznik says they consider the live image their 'polished product' where > > everything must work, while the DVD install is more of a grab-bag - they > > install a whole bunch of stuff, and don't think it's the end of the > > world if one or two bits are broken. > > > > Given that, I propose re-wording as follows: > > You are trying to fix the problem on the wrong end thus leave the > criteria as is. > > The installing should not differ ( or in other word be consistent ) > regardless if you install from the live or from the dvd the end result > should be the same. > > You should have the same service enablement, the same desktop instalment > and experience etc. > > So get releng to get their act together and fix that for the dvd so > matches with the live. Per my long reply on the other sub-thread, I'm fine with that if it actually _happens_. But it's not releng's responsibility; it's the KDE and desktop SIGs. They own this stuff: it's their responsibility to choose what packages go in the lives and what packages are deployed when you do a DVD install of their desktops. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Re: Criterion revision proposal: KDE default applications
by Adam Williamson 13 Dec '13

13 Dec '13

On Fri, 2013-12-13 at 05:38 +0000, "Jóhann B. Guðmundsson" wrote: > On fös 13.des 2013 04:06, Adam Williamson wrote: > > it was -1'ed at go/no-go meeting in about five seconds. No-one voted +1 > > blocker on it. > > For the first I was not present there since I arrived later then usual > due to $dayjob but otherwise I would have voted +1 on it ( which would > have then just have been me ) + most of individual present have been > voting to push the release out the door to meet that arbitrary deadline > we never make anyway which renders this argument mood. Well, it's not an arbitrary deadline. It's the release schedule. Fedora's supposed to be strongly tied to its schedule; we're not a feature-based release project. So, it inevitably has to be the case that we have to calibrate our quality standards to what it's practical to achieve, in terms of testing and fixing, approximately within that cycle. The way Fedora is set up, it is reasonable for us to slip, oh, say up to three weeks a cycle, to fix really serious problems. But we shouldn't be slipping almost every milestone for every release, which we are. We shouldn't be putting ourselves into positions, _repeatedly_, where we have the choice of fudging our quality standards or delaying releases for multiple months. When those things are happening, what it indicates is that there is a fundamental mismatch between the quality standards we're setting ourselves, the development goals we're setting ourselves, and the resources - in terms of overall tester/developer hours, i.e. a product of the number of devs and testers we have and the release cycle we chose - we have to achieve those things. The last few cycles we've theoretically set our standards at a certain point, and then not really got close to living up to them. If we say we're going to block on every possible partition layout, we need to test at least some reasonable representative sample of all possible partition layouts by, at latest, Beta RC1. That didn't happen. If we say we're going to block on every single app installed by default for either of two desktops, we need to actually test every single app installed by default on either of those two desktops by Beta RC1, and ideally keep doing it with every relevant change pushed stable after that. That doesn't happen. The current state is that we're setting a standard which we clearly don't have the QA resources to stand behind sufficiently within the timeframe the project is comfortable with spending on a release, and on freeze/test/stabilize cycles. Pete knows what's coming out of the three-product proposal, but somehow I don't see it making the freezes longer or the set of deliverables any smaller. If we want to maintain the standards of quality we claimed to be setting for F18, F19 and F20 and actually live up to them, we would need to either drastically increase the resources we dedicate to QA and bugfixing, or reduce the development goals we set. It never seems like it's on the cards to reduce Fedora's pace of development: no-one seems to have the appetite for it. No-one wants to be the person who says 'no, that is a nice sounding feature but we don't have time for it. Put it in the next release.' It never happens. So we're left with the resources. Red Hat does not have a dozen interns lying around the place we can feed into the Fedora QA hopper. We've certainly got excellent community testers, and some who've started contributing or contributing more in recent releases and helped hugely to make them less of a disaster than they could have been. But it's not like we're getting a dozen new volunteers who'll put in multiple hours per day on testing either. Extending the release cycle or lengthening freezes seems to be as unlikely to happen as reducing the development churn; look at how this thing with trying to make the F21 cycle longer is going with FESCo. So, the way I see it, if we can't significantly reduce the pace of Fedora development, significantly increase the number of QA and developer people we have available, or lengthen the release cycle or freezes to give us the effect of more resources dedicated to stabilization with the same number of people, we either reduce the expectations we say we have, or we keep on basically lying about what our quality expectations are and then coming up with paper-thin excuses as to why not meeting them doesn't 'really' mean we have to block, while running around like headless chickens throwing builds against the wall one day before go/no-go to fix a bug we didn't know about until 1.1 days before go/no-go. I dunno about you, but the headless chicken act and the hero validation runs are wearing on me. Maybe if we do what I'm suggesting, and we do well for a while, we'll start feeling like we're on top of everything and we have the confidence to move in the direction of increasing the standards again. But right now, honestly, can you say we're in a position where we're able to realistically meet all the standards we are claiming to set for ourselves? I certainly don't. I was the one who proposed the desktop criteria in the first place, and some of the pushback against them was based on the worry that we wouldn't have time to enforce them. At the time I said I'd stand behind them and make sure the testing got done. Well for a few releases I think we did, and I remember back around 15-16-17 I actually spent quite a bit of time _testing the desktops_, I didn't spend four months straight running anaconda for five hours a day. I also had time to talk to the desktop SIGs and ask them for help and just generally look after the desktop testing process. From F18 on, with the extra workload from anaconda being much more unstable (in the technical sense of 'changing a lot'), with the addition of ARM as a primary arch and cloud as a first-class deliverable and UEFI testing and more USB testing and all the other expansions that have crept into our workload, I really haven't been able to do that the way I did before, and no-one else seems to have stepped in and taken over. So now we have these desktop criteria we (QA) supposedly commit to 'policing', in the sense of actually running the tests and making sure things get fixed on a reasonable timeline, and I don't think that in practice that is actually _happening_. Now a couple of people have suggested reducing the KDE package set for the DVD install. Like adjusting the criteria, that would also have the effect of reducing the testing workload, so it seems like a reasonable approach. If that's what we want to do instead, fine. But we need the KDE SIG to agree with that approach and commit to it and land the changes, like, _now_. Comfortably in advance of F21 TC1. And we need to be sure that we (QA) can provide the resources to actually do the testing required to properly back the criteria: we need to be actually running all the desktop tests, frequently, during Alpha and Beta, and working with the desktop and KDE SIGs to fix the bugs. > The fact is it should not matter if I install from a live or from the > dvd the end result should be the same. That might be your opinion of what's correct. And hey, maybe everyone agrees with you. But the practical fact of the matter is that is not, at all, how Fedora as it exists right now works. For both GNOME and KDE, if you install from the DVD you get a significant number more packages than if you install from the live image. You do not get the same result. If we all agree that you should, and we go away and _actually implement that_ within the next, say, month, then great: that helps solve all our problems. Does everyone want to do that? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Criterion revision proposal: KDE default applications
by Adam Williamson 13 Dec '13

13 Dec '13

It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_app… jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: "All applications that can be launched using the standard graphical mechanism of a release-blocking live image after an installation of that image must start successfully and withstand a basic functionality test." So, that doesn't just apply to KDE. True, but I actually think it's a reasonable revision for GNOME as well. It makes sense to see the live images as defining what our 'polished core desktops' consist of, and the DVD as more of a grab-bag of packages. The lives will (should) always contain the bits the desktop SIGs think are absolutely key pieces of the desktop. And I think we could generally do with a bit of criteria watering-down; we're starting to do a lot of fudges and waives, which indicates the criteria are currently too tight for us to realistically enforce. Things are better when we can stand solidly behind the criteria without fudging stuff. CCing KDE and desktop lists. If folks feel that we should restrict this change to KDE only, please do yell, but I'm kinda liking the simple version. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Kontact stays running after closing 4.11.9x
by Colin J Thomson 08 Dec '13

08 Dec '13

Hi, I'm currently running/testing 4.11.97-fc20 and have noticed that on closing Kontact it stays running. This first appeared on this box after updating to the 4.11.9x series. I've found a bug report on kde.bugs and wonder if anyone else has seen this? https://bugs.kde.org/show_bug.cgi?id=222878 As usual thanks to all involved in providing the packages and a smooth update process. Colin -- Fedora 20 - Testing (Heisenbug) Registered Linux user number #342953

2 1

issue with batterymon
by Neal Becker 02 Dec '13

02 Dec '13

In recent kde (4.11.3 currently, but I've noticed over last 6 months or so), when my laptop resumes, sometimes (at random?) even though it's plugged into AC, batterymon keeps dimming the screen after a minute of inactivity - as if it was on battery. If I look at batterymon plasma, it says 'on battery (not charging)'

2 1

Emacs disappearing titlebar in x2go session
by Roderick Johnstone 02 Dec '13

02 Dec '13

Hi I'm seeing a curious effect with emacs (and apparently only emacs) in an x2go KDE session on Fedora 20 beta. As soon as the emacs window takes input focus the title bar disappears. I can still eg drag the window by grabbing beside the menu items though. Also, the emacs status bar (roughly 3/4 the way down the window) and stuff below it also disappears from the emacs window (at least as far as I can remember - my x2go session is broken badly at the moment). Does anyone have any ideas where I look to find out whats happening here, and hopefully prevent it happening again? Thanks Roderick Johnstone

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde December 2013