Red Hat Bugzilla – Bug 109906
[RFE] add better (more complete) documentation of changes to RELEASE-NOTES
Last modified: 2007-11-30 17:10:33 EST
Description of problem:
There needs to be better (more complete) documentation of changes in
new Fedora Core releases. Many of us do not have the time or
knowledge to understand the functionality changes which have been
incorporated into a new release. The individuals knowledgable of the
changes should add documentation to the RELEASE-NOTES or a "What's
Case in point which appeared on the fedora-list mailing list:
RHL9 shipped with gnome 2.2 whereas FC1 ships with gnome 2.4. In 2.4,
the configuration of the panel has changed dramatically and folks on
fedora-list were wondering if something was broke or just how to
configure things ... nothing was broke, it was just different.
While I realize that folks do not read the RELEASE-NOTE who should
because it answers their questions, they cannot read that which does
not exist. Expecting individual users to go out and find that change
documentation for all the packages is just not reasonable.
BTW, this "should" be filed against the fedora-release package but
that package name is not available under bugzilla.
Another example of something that needs documentation is menu editing
By default, editing of menus is disabled. However, if you replace
you can edit the menus. Currently, the only "documentation" I am
aware of are some email messages.
(Moved to fedora-release, as bugzilla has updated its package list for
Thanks for your submission. We are working on a number of changes to
the release notes creation process that will hopefully improve the
quality of the release notes. Specifically, we are restructuring the
release notes to make it easier for both users and developers to find
things; hopefully this will encourage more developer feedback -- it
will be easier for them to determine what is being said about "their"
software. We are also going to use bugzilla as a means of tracking
and discussing release notes content. This should reduce the problems
inherent in the current email-based process (namely the lack of a
single place to discuss each specific issue).
However, keep in mind that this is likely not going to completely
solve the problem. While you are correct that the people responsible
for any changes to functionality (namely, the developers) should
ideally be responsible for ensuring that this change in functionality
gets documented, the reality is that, for a number of reasons, this is
not always the case. Short of forcing developers to write stuff at
gunpoint, nothing is going to get 100% compliance; the best we can
hope for is to increase compliance as much as possible.
I'm going to close this with a "deferred" status, as although the
changes are in progress, it will be a while before we find out how
effective the changes have been. Feel free to re-open it if you have