On Mon, Jan 26, 2009 at 4:22 AM, Rahul Sundaram
<sundaram@xxxxxxxxxxxxxxxxx> wrote:
> Patrice Dumas wrote:
>>
>> On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha) wrote:
>>>>
>>>> Also, if the maintainer knows where the information about the update is
>>>> it could be nice to have it in bodhi, but not mandatory. Something like
>>>>
>>>> See some.site.org/release_notes.html for the changes.
>>>>
>>>> or
>>>> See /usr/share/doc/foo-1.0/NEWS for the changes.
>>>
>>> The first one is nice, but the second one causes a problem: how can
>>> you review the changes _before_ updating if the file listing changes
>>> is inside the updated package ?
>>
>> You can't. But this is something for upstream, in my opinion.
>
> If upstream does it on their own, package maintainers must add pointers to
> it. If not, the job of summarizing the need for an update rests with the
> package maintainers since they are the ones pushing it to end users. Package
> maintainers can help upstream in the process if necessary as well. Version
> numbers by themselves don't mean much, if anything at all since they aren't
> used consistently across different projects or even between releases. The
> whole point of enforcing a description field is to help end users get more
> information beyond just version numbers.
Sigh. I hesitate to get in the middle of this one, but...
Let's not make anything more difficult for the package maintainers,
eh? Over the last couple years we've already seen a slew of new
policy, requirements, etc, that make things more onerous for our
(largely UNPAID volunteer) maintainers; I suspect some are still
not-so-happy with having to go through bodhi for that. I know that if
I had to manually touch each update's notes, I'd be very hard pressed
to maintain my packages. Any policy along these lines seems like a
HUGE amount of extra work (every maintainer summarizing a changelog
that may or may not exist for every update) with little added benefit
(those who are likely to be looking at this are those who probably
know how to find and read a changelog; those who don't probably will
just update anyways).
Also, as others have pointed out, the rpm %changelog is the place to
summarize changes to the _delivered_ package, not the program itself.
e.g. "added examples/ to %%doc" or "resolved RHBZ#123456 by excluding
*.a from %%files" would be appropriate in a changelog, whereas "major
changes to the functionality of this version include the new
frobnicate feature of the Fedora Orbital Laser, ..." would be out of
place. Let's not overload %changelog to be something it isn't.
In any case, regardless of this, a couple solutions with little to no
maintainer impact present themselves to me:
1) Have the graphical updater tool present a message like "These are
the package update notes and changes as noted by the packager; for a
comprehensive list please find the package changelog through its
homepage at <url>"
2) Submit such a statement at the head of the bodhi update notes.
I'll be updating my bodhi-enh[1] script to do just this.
-Chris
[1] right now, something like this:
#!/bin/sh
set -ex
REL=`cat branch | sed -e s/-//`
make clog
bodhi -n -c "`cat clog`" -r $REL -t enhancement -R testing `make verrel`
--
Chris Weyl
Ex astris, scientia
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
