how to show upstream changes to the user

[Chris Weyl]

On Tue, Jan 27, 2009 at 3:04 AM, Dan Horák <dan at danny.cz> wrote:
>
> The keyword should be "automation". Why to copy&paste when it can be
> done by script. I can imagine a "hidden" field in spec (special comment
> like #changelog: http://....) that is transformed into a field in bodhi.
> It can be a macro in spec that gets evaluated before including in bodhi,
> etc.

Hmm, you know, one of the things the CPAN does [1] is to pull out any
README and META.yml the package contains...  While we don't need
either of those, and given how changelogs tend to fit a fairly regular
naming scheme (e.g. Changes, ChangeLog, various case permutations,
etc), why not emulate this as part of the update process?

e.g.

1) a scanning of the package for matching filenames, preference to
those under the %_docdir; if none found generate a dummy changelog
2) normalizing of the names and hosting somewhere (e.g.
Http://..../changelogs/Changes.packagename-x.y.z-rel
3) update the gui tool to display the link to this changelog as well
as the URL to the project, with something like "the changelog for this
release is at <above url>; you may find additional information at the
project homepage <rpm url tag>."

This will make it easy to get this information into people's hands and
is fully automateable.

                        -Chris

[1] Which has been around WAY longer than rpm, possibly even Linux, if
memory serves.
--
Chris Weyl
Ex astris, scientia