Bug 132384

Note that this is a bug in cpuspeed.patch, not in the original source.
 And perhaps it should be corrected by fixing the patch rather than
the documentation, for compatibility with the original cpuspeed.

I fully agree to the latter comment. The change from 1/10 to full
second in the interval specification is obviously a bug, especially if
the default interval (20) was kept unchanged. As it is shipped now,
cpuspeed is not doing the right job: waiting 20 (or more) seconds to
get CPU running at full speed is a nonsense! Most jobs (short
compiles, test runs, displaying images and so on) complete well before
any change in CPU freq occurs. And so the user has typically no gain
from his/her fast processor.
regards, Michal.

Created attachment 109233 [details]
Here is a patch to fix the -i parameter.

Here is a patch to fix the -i parameter.

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Changing version from fc2 to fc3.

The attitude of assuming that bugs have been fixed even if nobody has looked at
them seems like a bad one.  It just highlights the fact that many bugs aren't
looked at and discourages users from filing bugs.

I'm sorry, but Fedora Legacy doesn't have the resources to go through and
evaluate all non-security FC2 bugs; that's why we're asking for your help. 

We're *not* assuming that all such bugs are fixed, but rather showing the
reality that unless there's some activity, these bugs *won't* get fixed.


I understand what you're saying about how this may discourage users from filing
bugs, but I think it's better to reflect reality than to let these completely
languish and just have nothing ever happen to them -- that's pretty discouraging
too.

I often wish Red Hat developers would have an infinite amount of time,
resources, and energy to look at my issues too, but again, there's reality.
Fedora Core *is* a community project, and so often active participation is
required to get these things addressed. Hopefully, reducing cruft in Bugzilla
will make it more useful to the core developers and lead to *better* overall
response.

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

By source code inspection of a cvs checkout from fedora cvs, this is still an
issue in cpuspeed.patch in both FC-5 and devel.

(In reply to comment #6)
> I often wish Red Hat developers would have an infinite amount of time,
> resources, and energy to look at my issues too, but again, there's reality.
> Fedora Core *is* a community project, and so often active participation is
> required to get these things addressed.

If this is a community project, do you accept patches from the community? 
What's the process for getting patches (like the one on this bug) that are being
ignored to be incorporated?

I agree. It's a serious issue. Part of the point of this review of old open bugs
is to help get attention for the ones that need it.

This appears to be fixed in cpuspeed 1.2.1, which fc5, fc6 and rawhide all
feature now. Essentially the same thing proposed by the patch in comment #3 is
done within the program's main loop to convert to tenths of seconds.