test March 2009

test@lists.fedoraproject.org

172 participants
293 discussions

NVIDIA Question
by David St.Clair 17 Jan '22

17 Jan '22

This may be a dumb question, but why can't Redhat distribute NVIDIA binary drivers? In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it says: "2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux operating system may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files)." So, what's keeping RedHat from putting the drivers in the distribution? If it's a GPL thing, would it be easy to just download it during installation or at least give the option to the user? Thanks, -- David St.Clair dstclair(a)cs.wcu.edu

10 20

Mouse goes crazy
by Jonathan Villa 17 Jan '22

17 Jan '22

Ok, I have had Yarrow working well for a while now, but yesterday I started experiencing some odd issues with my mouse. All of a sudden it stops working correctly. The only thing that seems to fix is to kill X and run mouse-test, then restart. Any ideas? Also, I have FC 1 running on a desktop which is hooked up to a KVM switch. Whenever I go to another PC, and return, the same thing happens, the mouse goes crazy. ???

8 7

Re: digikam and kipi-plugins?
by Rex Dieter 22 Nov '15

22 Nov '15

Per Bothner wrote: > The Rawhide version of digikam is the very latest (0.10.0-rc1), > but it fails to find any of the "Kipi plugins", even though I've > installed the kipi-plugins package. This might be an upstream > issue, since 0.10.0 is pretty bleeding edge and the kipi-plugins > may even more bleeding-edge. Gwenview does seem to be see the > plugins, so I'm wondering if there is there might be a > Fedora-specific problem before I complain upstream ... The f10 builds seem to work fine for me (finding the plugins), so perhaps this is rawhide-specific? To be clear, digikam's Settings -> configure digikam -> Kipi Plugins is empty? -- Rex

2 1

Re: rawhide report: 20050419 changes
by Ray Strode 22 Nov '15

22 Nov '15

Hi, > Will yelp in FC4 be able to search and display man/info pages Yea, man and info pages work for me. --Ray

2 2

Mouse Wheel gone
by Christian Menzel 22 Nov '15

22 Nov '15

Since the latest xorg-X11 upgrade I receive the already mentioned XKB error and the mouse wheel is not working anymore. Has anybody seen this behavior? Regards Chris

3 3

Re: NFS failure
by Fulko.Hew＠sita.aero 22 Nov '15

22 Nov '15

Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM wrote: > On Wed, 7 Apr 2004, Jeff Elkins wrote: > > > I'm getting failure messages on my nfs mounts i.e. : > > > > mount to NFS server 'music.elkins' failed: server is down. > > > > nsfd appears to be running and I didn't see anything suspicious in the logs. > > The servers are up and running and have other clients connected. > > You didn't mention what steps you took to debug it: > > Can you ping the server? > What is the output of rpcinfo -p servername? > Does the server have access restrictions (firewall, TCP Wrappers, etc)? I have the same symptoms... rpcinfo says that nfs et.al. are running. Something has changed in test 2, since the same PC running RH9 accesses that host just fine.

7 9

How to Triage: Draft posted on wiki
by Christopher Beland 29 May '09

29 May '09

There is a new draft posted at: https://fedoraproject.org/wiki/User:Beland/How_to_Triage I recommend moving this to replace: https://fedoraproject.org/wiki/BugZappers/How_to_Triage and changing the "Checklist" line on: https://fedoraproject.org/wiki/User:Adamwill/Draft_Bugzappers to "[[BugZappers/How to Triage|How to Triage]] - Includes checklists for use while doing triage" I recommend making [[BugsAndFeatureRequests]] the destination of the "Bugzilla Primer" link. I added some complementary content here. It seems fairly complete, unlike https://fedoraproject.org/wiki/BugZappers/UnderstandingBugzilla which I'm leaving as a subpage. -- Beland

10 41

QA group activities + goals discussion
by Adam Williamson 28 May '09

28 May '09

Hi, all. Just before I left the Raleigh office after my week for orientation and getting to know the rest of the QA team, we had a meeting to try and set some goals for Fedora QA for this year. 'We' is myself, James Laska, and Will Woods. In the spirit of community that I am supposed to be bringing to the team, I wanted to throw these topics open to the list to try and get your feedback on the same topics we discussed. Off the top, we should be honest and open: Red Hat pays Will, James and now myself to work on Fedora QA full time. In my case, what RH want from me is quite purely and simply to try and help the community - external contributors - to improve the quality of Fedora as a project. In Will's and James's cases, though, things are slightly different. Part of their value is to produce tools and work on processes that, as well as contributing to Fedora QA, also contribute to the process that ultimately improves the quality of Red Hat's other products. In addition to that, they're real engineers who know how to write stuff, and all engineers like to come up with ideas and implement them. So, given that, there are always going to be things that the internal QA guys are working on that are decided by RH or by themselves. No matter how open and community-friendly we are, it will never be the case that the work and goals of those paid by RH are entirely determined by the collaborative process. However, bearing that in mind, it's still very valuable to RH, Fedora, and the Fedora QA community to hopefully get all your opinions on these issues, and it can certainly help to set my goals and help everyone involved in this project think about what they're doing, what they'd like to do, and how we can all work together towards the ultimate goal of making Fedora an even better project. So, to the topics! We set ourselves three simple questions 1. What does Fedora QA do? 2. What should it do? 3. What should it do first? We'd like all of your input on these questions - just let us know what you think. Broadly, we identified several things we - as a project - do: * Exploratory testing: simply using Fedora, updates-testing, or Rawhide, and complaining when stuff breaks. We agreed that this is at least as important as anything else QA does, but sometimes isn't treated as such. We agreed we should always emphasize that this is important and valuable, try to help ensure it can be done as effectively as possible (through things like the Bugzappers project), and try to always communicate to everyone that simply doing this kind of testing is an important and valued contribution to the QA project. * Structured testing: this is the more in-depth testing we do, such as regular testing of specific functions based on test plans, the use of automated tools such as Beaker and Nitrate (once they're ready), and test days. It also covers the case where another group contacts us with a request to do specific testing on a certain function. A lot of discussion here covered the Beaker and Nitrate projects; my take on this, as a new guy, is that they sound like really great tools that will help us a lot when they're ready. * Bug zapping: all the great work done by the Bugzappers team, mainly triaging and following up bugs to ensure they're properly handled from report through to released update. * Tooling: this is the work done, particularly by Will, to write the tools that allow structured testing to take place. We agreed that it would be good to get more contributions to this area, and that it's important to communicate the tools we do / will have available so they can be used to their full ability. This is important for things like Bodhi - we'd like to make sure that kind of system is more widely used. We also had discussions on things arising from the above, like the importance of Rawhide, and meta-tasks like documentation and community relations, which are important in attracting and enabling people to do the actual tasks. We also identified some specific goals. See also this Wiki page I created: https://fedoraproject.org/wiki/QA/Goals 1. Increase participation in Rawhide: it provides a huge benefit in terms of identifying issues and having them fixed quickly and early in the cycle. I am going to work on communication and documentation issues around that, and Will is going to work on producing a tool which simply tests, every day, whether you can a) install Rawhide fresh and b) update from latest stable+updates to Rawhide. This serves two purposes: it both lets you know whether it's worth actually attempting to install Rawhide that day if you wanted to know, and if we track the results over time, it provides an incentive to the developers to improve the reliability of Rawhide. 2. Make release testing more accessible Encompasses many sub-tasks. * defining what role QA serves in the release process * defining what QA can do during the release process * how can the community get involved? * who tests what, when, and how? This is what we're doing at present with the Wiki cleanup: the purpose of this is to make it easier for people to get involved and know what we do. 3. Strengthen the QA tools portfolio: aim to have Nitrate available in prototype form by June, as we believe it will be really useful both in improving the amount and quality of testing we're able to do, and providing a fun and easy-to-use system that will get more people involved with QA. There's also Beaker, which may take longer. This is what wwoods is mainly working on. So, what's your opinion on the above? Do you have anything to add to the lists of what QA does, or should be doing? Do you feel there are any specific problems stopping us performing at our full potential, that should be solved as soon as possible? Do you have any ideas on making QA more accessible and getting more people involved? Please let us know. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

10 23

Testing the Fedora 11 Installation Guide
by Adam Williamson 07 Apr '09

07 Apr '09

Hi, folks! Every release, the dedicated volunteers in the Documentation team produce the Fedora Installation Guide, an exhaustive and detailed guide to installing Fedora. For Fedora 11, they have asked us in the QA team to co-ordinate 'testing' of the Installation Guide. By doing installations following the instructions in the Installation Guide, we can find issues in both the Guide and the installation process itself, and thus improve both. So, I have written up an installation guide 'Test Case' here: https://fedoraproject.org/wiki/QA:Testcase_installguide As you can see, essentially what we'd like you to do is to take a look at the Fedora 11 Installation Guide as it currently stands - it's at http://docs.fedoraproject.org/install-guide/ - and try installing either Fedora 11 Beta or current Rawhide according to the instructions found in the Installation Guide. Report any problems you find - any bugs in the installer itself, or errors or missing information or bits where what's written in the guide doesn't correspond to what you see in the actual installer - to Bugzilla. As this is a wide-ranging case which doesn't involve any particular component or developer, we aren't running a Test Day for this, but instead would like it to be an ongoing process throughout the rest of the Fedora 11 release cycle. Please, if you have the spare time and resources, try and take part in this testing! Please discuss any questions, problems or issues as a reply to this thread. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

7 10

Draft for 'Bugzilla processes and procedures' mail to developers
by Adam Williamson 06 Apr '09

06 Apr '09

Hi, guys. As discussed in this morning's meeting, I'm sending a draft of a mail I propose to send to fedora-devel-list to ask for the opinions of the developer group on what we should do about Bugzilla policies and procedures. Does it look OK to everyone? Any suggestions to refine or improve it? Thanks! --------------------------------- Hi, -devel-list folks! We in the Bugzappers team (part of the QA group) are working to revise our Wiki space, and as part of that, various questions have arisen with regards to Bugzilla procedures. A lot of the same issues have come up on this list in the recent past. In general, it seems like Fedora doesn't really have a properly defined procedure for exactly how a bug should flow. Every maintainer, reporter and triager has a slightly different idea of what each status or resolution or keyword means, and when and by whom they should be applied. This is obviously confusing and problematic for any attempt to manage or monitor Fedora bugs in a systematic way. We should have a consistent procedure which works for reporters and developers and can be monitored and managed by the Bugzappers group. So, to arms! General bug flow ---------------- This section covers things like "what do all the statuses mean" and "what do all the resolutions mean" and "who changes what from what to what, and when". There is a very well-defined procedure for handling bugs in RHEL. The first proposal is that we simply use the same procedure (and hence the same statuses and resolutions) for Fedora. This has the advantage of giving us a well-defined and tested process which some maintainers will already be familiar with. The disadvantage of this is that the RHEL process is probably in some ways over-engineered for Fedora: it uses several stages managed by different teams which don't really exist so far as Fedora is concerned, and relies on certain automatic steps which aren't, AFAIK, actually automated for Fedora. The second proposal would be to adopt some kind of simplified version of the RHEL process, using a subset of the same statuses and resolutions, usually to mean the same thing RHEL uses, with a less complex procedure for getting all the way from file to fix. The third proposal would be just to come up with a process for Fedora from scratch, based probably on some kind of consensus around the current practices used by various groups. Specific issues --------------- So, that's the overview. To get down to some specific issues, here's the two big ones that have come up: 1) How to handle bugs that occur in multiple releases There's no obvious One Good Fix for this one, because Bugzilla just isn't designed to handle it. The two options most heavily discussed within Bugzappers so far have been: i) have reporters file separate bugs for each affected release that someone cares about ii) track all affected releases via one bug, using comments or keywords Myself and Vincent Danen tried to come up with a flag-based system for Mandriva to solve this problem once, but we couldn't really come up with something that would work better than issue ii) above. Personally I happen to prefer option i), but either can be made to work. The most important thing is to pick one option or the other and apply it consistently. This would mostly be the Bugzappers team's job, but maintainers obviously have to know the policy chosen and work with it, and Bugzappers don't want to try and just impose one choice or the other, we want to know what would be most comfortable for maintainers. 2) What do we do with the Severity and Priority fields At present these are pretty much roundly ignored by everyone (mostly on the basis that they're initially set by reporters, who don't follow any particular procedure, and so they don't convey any useful information). I personally favour a policy whereby the Bugzappers group would set these as a part of triage (their choices could be overridden later by the package maintainer or RelEng). Severity should indicate the importance of the issue *in the context of the package*, while Priority indicates the importance of the issue *in the context of the distribution as a whole*. So a crasher bug in a package only two people in the world ever use may be High severity but Low priority, while say a missing icon for Firefox might be Low severity but High priority. In my experience, if these fields are consistently set by triagers according to an agreed policy, they do convey valuable information to maintainers and maintainers (and RelEng) find them useful. Please, any feedback from active maintainers is most valuable - what I'm trying to do here is find out what those who use Bugzilla at the sharp end most need it to work like, to make their work most efficient. We in Bugzappers see our mission as helping reporters to file useful reports and maintainers to fix bugs as quickly and easily as possible, so we want to set our policy based on what will work best for reporters and maintainers. Thanks! ---------------------------- -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

4 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test March 2009