2:39 a.m.
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
Dan
2:49 a.m.
Dan Horák schrieb:
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.
Ideally changelogs could be RSS/atom feeds which can easily be parsed
and shown in packagekit. Packagekit (or Bodhi for that matter) could try
to download the feed and if it has the correct MIME type and formatting
extract the version's changelog.
The title of the feed should be something like "<package name>
<version>" so that Bodhi could extract the correct version. All this
would take is kind of a blog category/tag that produces only the version
information, since this is only using standard technologies most people
will not need to do much besides actually creating the entries. Maybe
bigger sites like sourceforge will pick up this idea and provide such
information automagically for hosted projects.
What this takes is package maintainers asking upstream to provide such a
feed. Alternatively we could write a few scripts that are able to parse
the most common ChangeLog formats and produce the feed from that.
I'm aware this is a huge task, but it would be useful, streamline the
workflow for upstream->downstream communication, and give more info to
users that really want it (I do, just thought about the Bash 4.0rc1
thread with missing changelog info, the only way to read being to
download the tarball).
Just thinking into the wild here,
Tim
--
Tim Niemueller <tim(a)niemueller.de> www.niemueller.de
=================================================================
Imagination is more important than knowledge. (Albert Einstein)
3:06 a.m.
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.
I didn't ask for upstream changelogs to be rewritten within bodhi. If
there is a upstream changelog, just adding a reference would be very
helpful. If that can be automated, that's great.
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.
This might solve part of the problem. It doesn't solve the problem where
downstream bugs are not referred to or closed for example. The thing is
that this process requires human intelligence and cannot be completely
automated in all cases.
Rahul
4:23 a.m.
Rahul Sundaram píše v Út 27. 01. 2009 v 14:36 +0530:
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.
I didn't ask for upstream changelogs to be rewritten within bodhi. If
there is a upstream changelog, just adding a reference would be very
helpful. If that can be automated, that's great.
> 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.
This might solve part of the problem. It doesn't solve the problem where
downstream bugs are not referred to or closed for example. The thing is
that this process requires human intelligence and cannot be completely
automated in all cases.
There is some support in Makefile.common to transfer bug numbers from
package changelog to bodhi.
Dan
5:19 a.m.
Dan Horák wrote:
There is some support in Makefile.common to transfer bug numbers
from
package changelog to bodhi.
Yes but the package maintainers have to fill in the bug numbers
manually. Whether it is done via changelog or bodhi doesn't matter much
as long as end users have that information available to them *before*
doing an update.
Rahul
4:28 a.m.
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.
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
b) have such a field in bodhi instead
- Panu -
5:04 a.m.
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,
etc.
Dan
6:05 a.m.
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(a)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 -
6:57 a.m.
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(a)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
7:12 a.m.
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.
8:21 a.m.
Michael Schwendt wrote:
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.
For the record the change log and reference to bug fixes either in our
bugzilla or upstream
are extremely useful information for at least testers,triagers and other
developers to monitor.
So please contain either an http url to the upstream changelog file or an
file:///usr/share/doc/<component>/changelog at least in the rawhide and
updates-testing report.
Both the http an file url are easy to use click able solutions.
And please do not remove the reference to a report(s) in bugzilla
This tell testers absolutely nothing
- New upstream version
- Update to
- Lots of bug fixes
What does the new upstream/update version bring?
which feature(s)?
which bug(s) got fixed?
While this does....
References:
[ 1 ] Bug #471709 - add sh architecture support
https://bugzilla.redhat.com/show_bug.cgi?id=471709
Update to kernel 2.6.27.12:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.10
Well you could of course provide testers with test cases each
time an new update/version is released instead of provide a reference to
the bug(s) that
are fixed and an url to the changelog so QA could come up with those
test cases if needed.
JBG
10:51 a.m.
On Tue, 27 Jan 2009 14:21:20 +0000, Jóhann wrote:
For the record the change log and reference to bug fixes either in
our
bugzilla or upstream
are extremely useful information for at least testers,triagers and other
developers to monitor.
Maybe. Maybe they are useful. What problem does it fix, though?
There is not much testing activity outside of bugzilla PRs. And the
triagers still touch bugzilla tickets without reading any part of it.
If, however, you want to raise criticism about specific RPM %changelog
entries, let's discuss some examples first.
So please contain either an http url to the upstream changelog file
or an
file:///usr/share/doc/<component>/changelog at least in the rawhide and
updates-testing report.
Why?
You can visit the upstream URL and hunt for news there if you have
strong/reasonable interest in a package. You can download the src.rpm and
examine the upstream tarball contents, or you can skim over the %doc files
included in the binary rpms.
The stronger your interest in a package, the more you ought to volunteer
as a package co-maintainer. Preferably we have a good mix of power-users
and package maintainers for every Fedora package.
Both the http an file url are easy to use click able solutions.
The file URI is useless IMO. For uninstalled packages it points to a
non-existant file. A web page URL adds maintenance overhead just like the
"Source" URLs, btw. There are locations, which change silently, whereas a
package maintainer notices changes in the update tarball.
And please do not remove the reference to a report(s) in bugzilla
Most package maintainers mention bz ticket numbers in the %changelog.
That is more than enough.
This tell testers absolutely nothing
- New upstream version
- Update to
Both are good enough in a %changelog, as they sum up the only change
that has been applied to the RPM package. If you're interested in
details, look out for developer's ChangeLog (or NEWS files, e.g.).
- Lots of bug fixes
That is a sufficient summary for a version upgrade, which is advertised as
a bug-fix release. If the RPM package users have not submitted any PR, it
seems they are not affected.
What does the new upstream/update version bring?
which feature(s)?
Where upstream README or NEWS files, which can be included in a package as
%doc files, don't cover such details, step up and become the upstream
project's documentation writer.
which bug(s) got fixed?
Monitor the upstream bug tracking system if you are seriously
interested in such details.
Well you could of course provide testers with test cases each
time an new update/version is released instead of provide a reference to
the bug(s) that
are fixed and an url to the changelog so QA could come up with those
test cases if needed.
You show a misunderstanding of what upstream maintainers and distribution
package maintainers are supposed to do.
Except for a few key packages in Fedora maybe, the majority of package
maintainers have zero expectations with regard to any QA. There simply is
no one to do such QA, not even WRT packages submitted as stable update
requests.
9 a.m.
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
2:24 p.m.
On Tue, Jan 27, 2009 at 3:04 AM, Dan Horák <dan(a)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
10:41 a.m.
On Tuesday 27 January 2009, Panu Matilainen wrote:
- 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 suppose this has been asked/suggested before, but how about changing rpm so
that its spec file parser doesn't error out but rather issues a big warning
when it sees a tag like structure it doesn't understand, and ignores it? And
add a command line option like --lenient to rpmbuild that enables this
behavior (default would be "strict" like currently). After this option has
trickled to all supported environments, every use of a newly added tag would
no longer render the package unbuildable with earlier rpmbuild versions.
1:36 p.m.
On Tue, Jan 27, 2009 at 06:41:14PM +0200, Ville Skyttä wrote:
On Tuesday 27 January 2009, Panu Matilainen wrote:
> - 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 suppose this has been asked/suggested before, but how about changing rpm so
that its spec file parser doesn't error out but rather issues a big warning
when it sees a tag like structure it doesn't understand, and ignores it?
Or allow RPM field names to be listed in a configuration file. The
ones which RPM doesn't recognize, but which are in the file, are
ignored. You break compatibility once, but allow future versions of
RPM to handle all future tags with relative ease (just add them to the
configuration file of earlier versions).
Did that make sense .....
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
5570
days inactive
5570
days old
16 comments
10 participants
participants (10)
-
"Jóhann B. Guðmundsson" -
Chris Weyl -
Dan Horák -
Michael Schwendt -
Panu Matilainen -
Rahul Sundaram -
Ralf Corsepius -
Richard W.M. Jones -
Tim Niemueller -
Ville Skyttä