Lack of update information

[Mark McLoughlin]

 On Thu, 2009-01-29 at 12:20 -0800, Chris Weyl wrote: 
> On Thu, Jan 29, 2009 at 2:08 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> > On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
> > > Good job :-) But this whole exercise is futile. We DO ALREADY ship both
> > > the ChangeLog and the NEWS files in the documentation directory, either
> > > with the library or development package. How is repeating or summarizing
> > > these internal changes *on Bodhi* useful to anyone ?
> >
> > Kevin's summary does something the NEWS file does not - it calls out a
> > particular crasher bug that could affect user applications. IMHO, that
> > is the only truly compelling reason a user has to apply this update and
> > it is the most user relevant part of Kevin's description.
> 
> We already provide the ability to link to bugs in the update; I don't
> see the logic in duplicating the information here.
 
Agreed, if a bug fix update includes the bugs it fixes in the Bugs
field, it is in good shape already.

Updated the text to read:

   Fedora users who do not update automatically may review the
   descriptions attached to updates before choosing whether they should
   apply them.

   Package maintainers should bear this in mind when preparing updates
   in bodhi and try to help their users make as informed decisions as
   possible. The Bugs and Notes fields are all the information which
   users have available when reviewing updates in the PackageKit UI (and
   not e.g. the RPM %changelog entries).

   Some suggestions on what to include in an update:

   1. For bug fixes, the appropriate bug numbers in the Bugs field
   2. For security issues, links to the appropriate CVEs 
   3. For new upstream releases, a summary of the important changes
      and/or a link to the upstream changelog
   4. Any other information that might be important to users

   Good judgement is required, though. Overly verbose descriptions can
   be almost as useless as overly terse descriptions.

Thanks,
Mark.