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

David Timms dtimms at iinet.net.au
Sat Dec 13 02:20:49 UTC 2008


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.




More information about the fedora-devel-list mailing list