On Dom, 2016-12-04 at 20:57 +0000, Iiro Laiho wrote: After waste sometime on understand what happened to Finnish keyboards layout, I don't think you can blame Fedora project, looking at upstream sources and releases [1] from xkeyboard-config-2.18 to  xkeyboard-config-2.19, we got one commit with "rules: Move Finnish DAS layout to extras", I understand you are angry (you lose keyboard layout) but also saw that layout just was added in 2015-09-29 [3] ( xkeyboard-config-2.16 ) You have some options , it might be interesting have extras layouts in Fedora , but I thin you should comment on upstream bugzilla with autor of the commits , the autor first add layout to xkeyboard-config and one year later move it to extras maybe he knows set keyboard with DAS layout in other way, for example also Indian layout has moved to extras  [4] says "For Indian languages, the input methods supplied by ibus- m17n  appear to be more useful" have you tried dnf install ibus-m17n ? and run ibus-setup ?  [1]  https://cgit.freedesktop.org/xkeyboard-config/log/ [2]  http://c.seres.fi/DAS_en.html [3] https://cgit.freedesktop.org/xkeyboard-config/commit/?id=d9135dd2b4982ead... [4] https://cgit.freedesktop.org/xkeyboard-config/commit/?id=913af7dafaab8ff4... -- Sérgio M. B.

But isn't it quite exceptable that things can break when one version- updates upstream components like this? After all, they are just building blocks of operating systems, not finalized products in themselves. Isn't it the job of the distros to make sure that things do not surprisingly change, or does freedesktop.org actually promise some kind of stability on their components? -- Iiro Laiho

I don't think the base.xml file is that incomprehensible. If you remove layouts from it, you can be pretty sure that they will be removed from the menus. But what it does actually mean? I wouldn't call three pseudonymous total amateurs yelling "works for me" quality control. While Fedora likes to claim otherwise, one should probably see Fedora as a some kind of test bed for new technologies and those who do want actually reliable distro should look at things like CentOS. This regression could have been avoided by thinking before committing, but it wasn't. And by the way, flatpak seems to be broken for X11 users because a some kind of X server permissions problem and no one seems to care. Traditionally though such kind of major bugs have been fixed quickly, but apparently not now.

No. I am just describing the current QA procedure. The +1 comments from three people are seen as some kind of proof of stability of the update, and those commenters don't go through any screening of any manner. "Works for me" really is a common expression in those comments. That we often don't know anything about those random people that happen to comment the update and still trust their word *is* a part of the problem. You should understand that falsely accusing people of insults isn't in any way respectful either. How putting words into my mouth is "respectful"? I am helping. Without me investigating and reporting the problem, the package in question would maybe still be broken. But I am just one person with many things to do and cannot bend myself to substitute a whole QA system. But I have to agree in that the current situation can sometimes except the maintainer to know everything about their package, and such exceptation is unrealistic.

Liro the QA team do the best they can to test updates before they go to stable, but you hit a diferent issue, there is not enough people testing packages before going to stable. My keyboard layout is spanish, most QA people have a English keyboard layout, I can update and I do not note the missing layout, so it is valid for me to say than the package "work for me" because it does, I do not change the desktop layout after a update, you hit a issue than can be easily identified by a user of this layout but it was not a tester of this layout, you can help this thing of issues to no become a stable update in the future, criticizing do not help to much.

On Thu, Dec 22, 2016 at 01:27:34AM +0100, Kevin Kofler wrote: I think simply blocking autokarma on _any_ -1 is a good solution to this. Not blocking manual pushes, but requiring the maintainer to at least check. https://github.com/fedora-infra/bodhi/issues/879 I don't see any problem with automatically pushing updates (after a minimum timeperiod as discussed in another thread) that have gotten only positive feedback. As a maintainer, I was going to push that eventually, and having it happen when I know some other humans were involved to a given threshold is nice. And, Kevin, seriously, please stop throwing around "silly" for things other people worked on that you disagree with. It makes it harder to do _everything_. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

Adam Williamson wrote: A completely hypothetical example. The events that eventually lead to the current Bodhi rules were much less drastic than that. Kevin Kofler

Kevin Fenzi wrote: I don't recall it either, so that's already 2 people. And I tend to remember such things. So you should in fact doubt it. Do not believe everything you read on the Internet! This had a one-line command-line workaround (to get the fixed package over the yum command line, working around breakage of the GUIs). It actually came out of a single bad "bind" update, affecting the BIND server only (not the client libraries), a package that the vast majority of Fedora installations does not even have installed to begin with. That issue was also perfectly fixable by just SSHing into the affected machine by IP address (and you definitely SHOULD know the IP addresses of your servers! Or at least you will be able to find them out) and running "yum update". The really fatal update issue in 2010: https://fedoraproject.org/wiki/Updates_Lessons#2010-07-07_-_PackageKit_no... actually happened WITH the new policy, proving that it does not work, at all. (And also that SELinux breaks things, but nobody other than me even considered disabling SELinux in response.) In addition, before the Bodhi policy changes, in such cases, it was possible to push the fixed package directly to stable, minimizing the exposure time and thus the number of affected users. This is also made impossible by the new policy, so you end up with more users getting hit by the fatal regression, and the fix is harder to get (one has to enable updates-testing). Not to mention other fatal side effects of the policy such as: https://fedoraproject.org/wiki/Updates_Lessons#2010-11-11_-_proftpd_remot... of which there were (and still are!) actually dozens of instances, but nobody wrote them down after the first. Kevin Kofler

On Sat, 2016-12-24 at 09:07 -0700, Kevin Fenzi wrote: If I were you, I wouldn't trust me all the time ;) As a general rule, when I say stuff in passing with weasel words around it, go check. I'm probably just relying on my memory, which is at least as bad as anyone else's. When it's one of my four page emails with two pages of footnotes, that means I went out and actually checked my references. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

On Wed, Dec 21, 2016 at 4:36 PM, Iiro Laiho <ilmaisin(a)fedoraproject.org&gt; wrote: They are not random people, it is definitely a non-scientific sample of users, with FAS accounts, who contribute feedback that varies along a continuum between subjective and objective. There is no practical way to completely test all faucets of a package before its release into the wild. Saying people should not be trusted merely because you say so is an amusing strategy. Nor is accusing contributors of being "total amateurs" nor is accusing them of "yelling". Looks to me like you can dish it out the insults but don't like being called out on it. Your language is inexact, I suggest cleaning it up and aim for better precision if you think you're being misunderstood. Well it seems to me if a packaging change means some files are going to be removed upon updating that package with the new (and changed) package, that it's reasonable something somewhere is going to break, and that this should cause the build to fail with a warning so at least it can involve a human to assess the likelihood for breakage. But I'm pretty sure that automation doesn't happen right now and the process depends on people simply hitting the problem and reporting it. It's more correct to say the automated testing of package has a hole in it, rather than blaming people for whom the package did in fact work and caused no regressions. That feedback wasn't wrong and it's inappropriate for you to suggest they were wrong to up karma the package, that they are therefore total amateurs, and that they were yelling about anything. -- Chris Murphy

On Wed, Dec 21, 2016 at 6:42 PM, Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: Yep. The should was supposed to be a could. OK so it's just an ordinary oops moment, dust oneself off and get moving again. -- Chris Murphy

On Thu, Dec 22, 2016 at 11:08:21AM -0000, Iiro Laiho wrote: We are a community of world-wide volunteers working on making a linux distribution so we are pretty much a community of people on the web. As such which screening would you want to see before trusting our contributors? I think everybody will agree that the web is large and some corners are darker than other. The project at large got some large waves of spams hitting us in the last months, so we are aware that the world isn't all unicorns and kittens. But putting screening in place in a way that isn't counter-productive to how a community is built (which I believe is: trust) seems like a difficult task. So what are you thoughts and ideas to try improving, extending our community while developing a sense of trust in our fellow contributors? Also, let's not forget that we are speaking about: - a community member that is trusted enough to have access to our packages and build system pushed a new package update - other community members are reporting pro/against this update In this last step what is the worst that could happen? Random people giving negative or positive feedback just to annoy us? So the packager will loose a time figuring out if the comments/feedbacks are legit and go to bodhi and click on the ``Push to stable`` button instead of relying on autokarma? Seems to me like the risk here is pretty limited, we're not talking about something that would be critical to our infra. Pierre

Quality control can be a thank-less procedure but a very important one that can mean many things to different user groups ie developers or just a regular users - each group has was it priorities are important to them. In a community driven environment it is important to get the mix correct and too ensure that the product remains stable as possible, that all contributors are heading to a common good as what a packager may see as important may or may not be important to the end users. It is ensuring that processes are in place to allow people to contribute easily to any part of the project and ensure that they feel their contribution is worthwhile and respected, and ensuring that the politics are kept to a minimum. Car-clubs are the same and the best one do it well, community based software development may learn from people that have seen things go off the rails and affect community projects to their detriment or destruction. I have been a long time user of fedora products and respect the people that have contributed over the years, but their are signs that some things could be done better but will always depend of resources being available and someone to do it. This needs fostering in any community project IMO to do well. Keep the politics out of the way. Regards Timothy Ward On Thu, 2016-12-22 at 06:56 -0500, Matthew Miller wrote: > On Thu, Dec 22, 2016 at 11:08:21AM -0000, Iiro Laiho wrote: > > Yes, I should have been more clear about my intentions. I admit I > > was > > frustrated when I wrote the message. Please do not interpret other > > people's writings in the most hostile possible way. > > Thanks. This too is in the code of conduct. :) > > >

Hi Laiho, your bug was fixed less than five hours from the report. Keep in mind that is a bit hard to find an issue in a specific Language, so please do not blame testers/QA guys. Feel free to always report these situations and keep contribuing with tests/patches. Cheers, Filipe R.