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

Re: how to show upstream changes to the user

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.


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

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