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
Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM
> 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
> > 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.
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
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
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
1. Increase participation in Rawhide: it provides a huge benefit in
terms of identifying issues and having them fixed quickly and early in
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
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
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.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
If you would have a Linux system where in a default configuration
everybody with a desktop session would be able to modify at will such
"insignificant" system settings like values of a hardware clock and
a system clock, not mentioning such details like global changes to
a configured timezone, then would you think that this is:
- how it should be
- a minor boo-boo
- somewhat troublesome
- or a really serious problem of a system integrity with security
consequence too (messed up logs but not only)?
Now knowing that various programs will be seriously affected by
sudden changes in clock various, and ntpd is very careful when doing
clock adjustments, would you think that the situation described in
the previous paragraph is something which does not happen on Fedora
or maybe it does?
1.) In an effort to start cleanup, I merged
[[BugZappers/GettingStarted]] into [[BugZappers/Joining]] and cleaned
up links from the front page. [[BugZappers/HelpWanted]] should also
be trimmed and merged in there.
I also renamed [[BugZappers/TakingAction]] to [[BugZappers/How to
Triage]], so it has a clearer purpose.
2.) The subpages under [[BugZappers/HouseKeeping#Task_Breakdown]]
should probably be merged into the master page.
3.) [[BugZappers/components]] and [[BugZappers/FindingBugs]] are both
serving the dual purpose of tracking what needs to be worked on and
providing links to BugZilla to find bugs that need work. Any
objections to merging to [[BugZappers/Tracking]]?
4.) [[BugZappers/Joining]] and [[BugZappers/ActiveTriagers]] have
somewhat contradictory advice:
"This does mean certain components are reserved. If you are
unfamiliar with a component and someone is very active there, it is
probably a good idea to pick a different component."
"It is okay for more than one person to cover the same component"
We need to have clearer advice.
I also see that [[BugZappers/Special Procedures]] has a note arguing
that special opt-outs for certain developers are not scalable
I think it would actually be a good idea if we took the list at
[[BugZappers/components]] and merged in the list of people who are
working on a particular component. (Adding a second list for non
"key" components if people are claiming those.) The clearest
indication for new triagers would be to add a column to indicate for
each column whether or not more help is wanted for that component
("Yes") or if the existing triagers or developers think they have it
covered ("No"). But there are other ways to present this information.
5.) As for the other content on [[BugZappers/Special Procedures]],
[[BugZappers/How to Triage]] is the main instruction page, but we also
have [[BugZappers/BugStatusWorkFlow]] and lots of advice on
[[BugsAndFeatureRequests]] (which is oriented toward bug filers, not
Clearly we need the One True List of Things Every Bug Should Have,
which filers should supply and triagers will request if they don't.
(This varies by component, and type of bug - e.g. crashes
vs. misspellings vs. feature requests.) The ASSIGNED section of
[[BugZappers/BugStatusWorkFlow]] has some of that info, which can be
removed and replaced with a link to the canonical place.
BugStatusWorkFlow can then just be an explanation of Bugzilla states.
[[BugZappers/How to Triage]] and [[BugsAndFeatureRequests]] then need
to be harmonized and streamlined. This is the crux of the problem of
making a minimal set of instructions that bug filers and triagers
can actually follow.
6.) [[BugZappers/Meetings]] and the front page don't mention that
Triage Days are held immediately after meetings. Has that been
decided for certain?
After updating Rawhide today Emacs redisplay is dead slow.
The problem is when scrolling: even when only scrolling
by a single line, the whole window is redisplayed, and
it is done so very slowly - taking about two seconds.
This is only a problem with the default "Gnome window"
emacs - it is not a problem with emacs -nw (i.e. Emacs
in a terminal window), or other text editors I've
tried (kate, gedit).
The feature freeze is coming soon, and that means we need to check to
make sure all the new ans exciting features coming in F11 are
Here's a list of all the F11-approved features that haven't been
The wiki pages should tell you a bit more, but basically, we need to
make sure that each feature has two major things:
The Scope section is supposed to list the *complete* set of changes to
be made, features to be added, etc. Basically: it needs to tell you
what's going to change - what packages, what config files, and so on.
If the Scope section is vague, incomplete or missing, add this to the
bottom of the Feature page:
[[Category:Features with incomplete scope]]
And add a comment on the 'discussion' page. Be sure to put "--~~~~" at
the end of your comment - this will add a signature for you.
2) How To Test
This part should tell you how to check everything listed in the Scope
section. It should have a complete list of detailed instructions that
you (or I or anyone on fedora-test-list) can follow to test the feature.
If you can't follow the directions in the How To Test section to confirm
whether or not the Feature is working, add this to the bottom of the
[[Category:Features with incomplete test plans]]
And add a comment on the discussion page, as mentioned above.
If both these sections are complete and accurate and useful, add:
[[Category:QA approved feature pages]]
to the bottom of the page.
This information will be used to decide which features are ready for F11
and which ones aren't. If there's a feature you're keen to see in F11,
you can help - go review its feature page!
If the scope or test plan are incomplete, *please* ask the feature owner
what they're changing and how you can test it. You can help them write
those sections, which helps everyone else test *and* helps FESCo decide
whether to keep the feature or not. Everyone's a winner!