[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how to show upstream changes to the user

Panu Matilainen píše v Út 27. 01. 2009 v 12:28 +0200:
> On Tue, 27 Jan 2009, Dan Horák wrote:
> > Both sides in the "Lack if update information" thread are true. The
> > presented information about changes is almost useless for the user, but
> > rewriting the upstream changelogs into bodhi is a superfluous burden for
> > the maintainers. There is, in my opinion, a technical solution for this
> > issue that can make both sides happy.
> >
> > And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
> > upstream changelog and GUI package management tools can open a browser
> > window to show the content, like they do for the home page.
> >
> > pros:
> > - low overhead for maintainer
> > - can provide complete info to the user even when he/she skips some
> > updates
> > - allows changelogs per sub-package
> >
> > cons:
> > - slightly larger metadata
> cons continued:
> - It introduces a spec incompatibility, which can be taken care of in
>    Fedora land but not so easy for EPEL side of things. Dunno if our
>    buildsys ever does anything with the rpmbuild of the host system
>    (I seem to recall it doing some part there but could easily be wrong),
>    IF so this is pretty much a no-go.

I can't comment the buildsys issues, but it can be useful to break the
compatibility (in one direction only) now and then.

> Would be trivial to add, sure. The question is, would it make any 
> difference to either
> a) asking packagers to add pointer to existing %changelog when rebasing
>     packages

There is a chance that the changelog attached in the source archive is
developer oriented (based on CVS/SVN/whatever) while the web-based one
is user oriented.

> b) have such a field in bodhi instead

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,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]