how to show upstream changes to the user

Dan Horák dan at danny.cz
Tue Jan 27 12:57:34 UTC 2009


Panu Matilainen píše v Út 27. 01. 2009 v 14:05 +0200:
> On Tue, 27 Jan 2009, Dan Horák wrote:
> >> 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.
> 

Yes, there was a misunderstanding and your idea looks good.

> >> 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 :)

I am looking for possibilities too, so there is chance we will meet
somewhere :-)


		Dan





More information about the devel mailing list