Michael Schwendt píše v Út 27. 01. 2009 v 14:12 +0100:
On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:
> > >> 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 :-)
So far it smells like needless bureaucracy, which you try to advertise as
"low overhead for maintainers". Only few maintainers would be interested
in hunting for URLs of changelog web pages for minor/major releases. The
benefit would be small. Users of open source software packages, which are
sceptical of updates/upgrades, ought to fetch the source packages and take
a look at the documentation files in addition to the package changelog.
Conclusively, make it easy to fetch'n'browse the src.rpm for updates.
From my side this is purely technical discussion what and how is
doable
when such requirement will go into the guidelines after ratifying by
FESCo. I personally do updates via "yum update" so it useless for me,
but I agree that people using GUIs to update can find that information
useful though I am skeptical in general.
I tried to find the changelogs for few of my packages and adding 1 fixed
URL somewhere into the spec wouldn't be so hard.
The other thing is how to automatically add bug numbers from spec
changelog into bodhi - now it requires to have them one bug per line in
'#<number>' format, no other text on that lines.
Dan