how to show upstream changes to the user

[Panu Matilainen]

On Tue, 27 Jan 2009, Dan Horák wrote:

> 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.

To keep people on their toes, yes :) Part of the problem is that rpm has 
remained compatible for so long people simply take it for granted and 
whenever something new is suggested, bunch of folks goes wild over "but 
you cant do that it breaks compatibility to RHEL 3" or whatever.

>>
>> 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.

I sense a misunderstanding here... what I meant is instead of just 
the "update to x.y.z", drop in a link too - simply something like 
(taking sqlite has an example):

* Thu Jan 22 2009 Panu Matilainen <pmatilai at redhat.com> - 3.6.10-1
- update to 3.6.10 (http://www.sqlite.org/releaselog/3_6_10.html)

Having something like that in the existing changelog would mean it's also 
trivial to browse back in history, whereas a single tag would only point 
to the current release.

>> 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,
> etc.

If such a thing is in the package, obviously it should be pulled 
automatically by bodhi. You almost certainly need to copy-paste the link 
once anyway - if the field only exists in bodhi then there's just one 
copy-paste. Mind you, I'm not trying to shoot this down, just looking at 
possibilities :)

 	- Panu -