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

Re: Fedora Com System http://fedoraproject.org/ , un-release updates ?



Paul W. Frields wrote:
On Fri, Dec 12, 2008 at 10:42:13PM +0200, Muayyad AlSadi wrote:
the announce mailing list should be visible in some web site that support rss

and let firefox or any rss reader configured by default for it

Gmane provides this:
http://rss.gmane.org/messages/excerpts/gmane.linux.redhat.fedora.core.announce
I like gmane for this sort of archive tracking.

Would fedoraproject be OK, to add that as a link in the default web browser bookmarks ?

As well as http://news.gmane.org/gmane.linux.redhat.fedora.core.announce
, which shows the most recent item expanded out by default.

{no not the ugly mailing list archive on .redhat}.

However, don't miss the importance of:
http://fedoraproject.org/
http://fedoraproject.org/wiki/

While I might be expecting better response than is possible, it would have been a far improved user experience if the moment that the problem become known, that a prominent message at the top of both sites to inform them of the fau paux:
-----
2008-12-09 Tuesday: Special announcement: please defer updating your Fedora installation for up to 5 days while our developer community works on an incompatibility issue with some recently released updates. Deferring your updates will avoid the symptoms described below, and allow normal updates to work without using the workaround below.

:details link:

  Nature of issue:
Users who update the software on their Fedora (10,9 or 8) system between the 8th of December and 13th of December will be confronted by an incompatibility between gnome-PackageKit (the graphical update manager), and the DBUS application communication system. This is seen as: a recurring dialog stating "Failed to reset client - Failed to resolve"

  Resolution of issue:
Maintainers of the software packages involved are working to completely resolve the issue. This is expected to be begin testing within 3 days, and once QA process are complete be made available for general consumption.

  Workaround:
Since the issue only causes the GUI package manager to be unable to operate normally, the underlying package management system [rpm] and update tools [yum] continue to work correctly. If you are seeing the symptoms noted in the nature of the issue, then you can still use yum to update your system from the command line:
{like Paul's email}...
# yum update

This note will be updated once the updates have been released.
-----
So that took me 20 minutes to write. How much time would it have taken for infrastructure to make it available as an include on fedoraproject web pages ?

We really don't want or users to hit issues, _after_ we know about them. So given a user is likely to click on "update me" before reading any mail, web, or rss feeds, the second step should have been to make the dodgy update invisible/unavailable etc perhaps by:

- immediate issue an updated repo metadata that does not have the possible culprits visible (eg put current date on the most recent known good repodata

- immediately replace the .rpm files in the master repo with broken rpms
of 1 byte or something - so as not to waste download consumption. These would get mirrored widely, overwriting the dodgy rpm, and making them unavailable even though some mirror repodata says they are available.

- updating metadata to indicate a set of packages that will never exist
: eg PackageKit-1.2.3-4.does_not_exist.rpm

Are any of these things possible ? Issues ?
Could bodhi/release tools be extended to have a "Release Engineer" button saying revert repodata to date=xxx, so that it becomes easy to implement one of the above ?

DaveT.


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