Robert Scheck wrote:
On Tue, 27 Jan 2009, Rahul Sundaram wrote:
much more. We are doing a pretty sloppy job with updates and are
providing good information on why those massive amount of updates are
needed for end users. Just simply pushing the latest version isn't a
In general, I agree with you. Maintainers must and have to put information
and details into Bodhi when submitting an update. Just "upgrade to xxx" is
not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
an important security fix, details will follow in the next days or so" as
this already happend multiple times in the past. Usually then, it is a more
bigger security issue with remote impacts which has to pass through without
any stoppers except for or by the Fedora Security team.
I wasn't aware of this. This seems a very odd practise. Why is this
happening?
So yes, we need some kind of guideline, either some fazit about the update
or the upstream changelog (depends on what is understandable, so gcc, glibc
and friends are also some exceptions, I would guess). On the other hand,
the Bodhi stuff has to be handable for the package maintainer. Speaking for
me and the other unpaid Fedora package maintainers, it is our time, we like
to spend and we spend for the project. Making it unnecessary complicated
shouldn't be the goal at all: Keep it simple, doable and suitable for both
sides: Maintainers and users.
Absolutely. So would you mind drafting a guideline for this? My goal
from this as a end user was just to more intelligently cherry pick
updates (bandwidth issues, cost of connection etc) and some of the
updates give me zero information beyond just semi random version numbers
to do this. Another potential problem is that third party repositories
typically don't make use of bodhi or equivalent so the experience is
very inconsistent across updates.
Rahul
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
