FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-24-2008, 01:51 AM
Peter Gordon
 
Default Package Updates/Bodhi Notification Content Policy?

Hi, all.

[I use X/Mesa stuff as an example only. Many other package updates
contain similar problems, and the X/Mesa stuff certainly isn't one of
the worst. Also, "notable changes" and similar phrasing in this message
hereafter refer to any major bug fixes (such as those which resolve
crashers or problems which cause loss of data), new enhancements (new
features or changed subpackages), security fixes, and the like.)]

Recently, there have been a slew of updates (especially X/Mesa related
packages, though not exclusively) that have no helpful message in their
update announcements. The last several %changelog entries are included,
thankfully; but even those often fail to describe the update properly.

I, for one, have not updated my system's mesa-related packages yet,
because the new release (-37 versus -35) seems to cause rather severe
performance issues. (FPS in Tremulous, for example, drops from a normal
45-55 to barely double-digit.) I can imagine a similar situation with
dial-up users or users with limited bandwidth, such as with pay-per-use
connections: Is the update useful enough to spend the time and/or money
in downloading?

The only notification in today's X updates, for example, is that it
contains a new RC5 snapshot (and that's from the package %changelog).
From the perspective of an end-user, I am thinking "What's changed?
What's fixed? Any cool new features? Will the packages fix my DRI/OpenGL
slowness?"

Noting a new version or snapshot is a good thing, sure; but users should
not need to go hunting through down upstream changelogs or bug trackers
or to figure out why the package update is being issued.

I'd like to propose a short policy of sorts to ensure that users are
properly notified of notable changes.

1. Any such notable changes should be briefly described in the Bodhi
entry. Essentially, package maintainers should summarize the key points
of the upstream changelog for these.

2. Relevant bug numbers or IDs should always in the Bodhi entry, either
for Red Hat/Fedora bugs (in Bodhi's "bugs" field), or as bug numbers
from an unambiguous tracker (in the update comments). For example: "Fix
GNOME Bug 98765" is good; but "Fix b.g.o#98765" is bad, since that could
be (at least) bugs.gentoo.org, bugzilla.gnome.org, or even
bugs.gobolinux.org, et al.

Corollary: However, we don't want to be overly redundant in the notices.
If we already include a bug number in Bodhi's "bugs" field, and that
bug's title is descriptive enough, then it may very well be that simply
referencing that bug in the update will tell users what's fixed - since
Bodhi will automagically retrieve that and insert it into the
announcement. For example, if your update through Bodhi shows "bug
123456: App crashes: segfault when enabling option foo," then it is not
entirely necessary to note this fix in the update comments. Other
changes should still be mentioned (if any). Similarly, if the %changelog
includes a mention of these notable upstream changes, the update
comments do not need to also include them (since the %changelog entry is
also inserted as part of the update announcement).

3. Any and all attempted empty Bodhi updates with no bug references
should return an error message, telling the maintainer to add a brief
comment describing the change and/or referencing appropriate bugs (and
perhaps referencing this policy).

Simply being a new version is not always a good reason to update! On the
contrary, new versions often bring new bugs and potential regressions -
especially with snapshots of upstream sources instead of deemed-stable
release tarballs.

[Rawhide does not use Bodhi updates and is generally not intended to be
as stable as releases, so merely noting the version bump is OK in the
package %changelog, though I still recommend summarizing some of the
more important notable package changes.]

Thanks for your time!
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-24-2008, 01:59 AM
Peter Gordon
 
Default Package Updates/Bodhi Notification Content Policy?

On Wed, 2008-07-23 at 18:51 -0700, Peter Gordon wrote:
Noting a new version or snapshot is a good thing, sure; but users should
> not need to go hunting through down upstream changelogs or bug trackers
> or to figure out why the package update is being issued.

Wow, that wording was horrible.

Should read: "Noting a new version or snapshot is a good thing, sure;
but users should not need to go hunting through upstream changelogs or
bug trackers to figure out why the package update is being issued."

Sorry for the confusion..
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-24-2008, 10:44 AM
Erik van Pienbroek
 
Default Package Updates/Bodhi Notification Content Policy?

Op woensdag 23-07-2008 om 18:51 uur [tijdzone -0700], schreef Peter
Gordon:
> 1. Any such notable changes should be briefly described in the Bodhi
> entry. Essentially, package maintainers should summarize the key points
> of the upstream changelog for these.

Hi,

For the daily rawhide reports I think it is also interesting to have
more verbose changelogs. But the issue is this tends to cause a lot of
clutter. There are currently some packages which have a more verbose
changelog (like gimp), but if all packages will do this, the daily
rawhide reports won't get any easier to read.

Maybe it is an idea to add a new rule to the packaging policy, something
in the line of:

"If your package update contains a new release from upstream, add a link
to the full changelog of this new release in the %changelog field"

In the long term, maybe an extra field in the YUM or RPM database could
be used for such a thing, so that user-visible applications (bodhi,
packagekit) can present this information in a more sane manner (like
clickable links)

Regards,

Erik van Pienbroek


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-24-2008, 06:45 PM
Tom Lane
 
Default Package Updates/Bodhi Notification Content Policy?

Erik van Pienbroek <erik@vanpienbroek.nl> writes:
> Op woensdag 23-07-2008 om 18:51 uur [tijdzone -0700], schreef Peter
> Gordon:
>> 1. Any such notable changes should be briefly described in the Bodhi
>> entry. Essentially, package maintainers should summarize the key points
>> of the upstream changelog for these.

> Maybe it is an idea to add a new rule to the packaging policy, something
> in the line of:
> "If your package update contains a new release from upstream, add a link
> to the full changelog of this new release in the %changelog field"

+1 for that. The policy Peter proposes is, quite frankly, going to be
ignored --- it's far too much work to lay on package maintainers.
Not to mention that Bodhi hardly provides an interface conducive to
composing large, complex update messages.

regards, tom lane

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-24-2008, 11:43 PM
Peter Gordon
 
Default Package Updates/Bodhi Notification Content Policy?

On Thu, 2008-07-24 at 12:44 +0200, Erik van Pienbroek wrote:
> "If your package update contains a new release from upstream, add a link
> to the full changelog of this new release in the %changelog field"
>

I strongly disagree. As I said in my original mail, the whole point of
such a potential policy would be that users *should not* need to peruse
through upstream changelogs and whatnot. More often than not, they tend
to be very technical in nature and/or contain a significant amount of
relatively insignificant commits (such as porting to a new third-party
library API, build script fixes, etc.); and this - to me - contradicts
Fedora's goal of showing how helpful and user-friendly FOSS can truly
be.
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-24-2008, 11:51 PM
Peter Gordon
 
Default Package Updates/Bodhi Notification Content Policy?

On Thu, 2008-07-24 at 14:45 -0400, Tom Lane wrote:
> +1 for that. The policy Peter proposes is, quite frankly, going to be
> ignored --- it's far too much work to lay on package maintainers.

With respect, a simple "Add feature foo and fix bug bar" seems to me
very little extra work at all. Even for my own packages when there are a
lot of such notable changes, I include some of the most major in the
Bodhi comment, then a link to the full upstream changelog - so it would
not be terribly different from your idea alone...perhaps somewhat of a
superset (if I may use the term loosely enough).

> Not to mention that Bodhi hardly provides an interface conducive to
> composing large, complex update messages.

You can create one single file for the update notice, then merely use
that in combination with the CLI bodhi-client utility. See
https://fedorahosted.org/bodhi/wiki/CLI for more details. Copy/paste
with some minor editing (for the branch and dist tag) doesn't seem
terribly difficult. =P

--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 11:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org