From Fedora Project Wiki

< FWN‎ | Beats

(FWN #157 spellchecked pass1)
 
(71 intermediate revisions by the same user not shown)
Line 5: Line 5:
mailing list are summarized.
mailing list are summarized.


Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Nautilus Spatial-mode Flamewar ===
=== Would You Like to Write This Beat ? ===


The tired, old topic of whether <code>nautilus</code> should use "spatial-mode" as a default was re-opened[1] by MarkG85 in the form of a request for list subscribers to "vote" on the mailing list for a reversion to "browser-mode". In spatial-mode <code>nautilus</code> opens a new window for each directory unless one middle-clicks or holds the shift key down.
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward.


It was pointed out by several contributors that voting "+/- 1" was not a recognized way to achieve change within the Fedora Project. [[ChrisAdams|Chris Adams]] asked[2] if he and his friends "[...] should [...] all spam fedora-devel with `+1' and `metoo' to change the default background color? What if it is 20 friends, or 100, or 500?" A similar point was made[3] by [[JeffSpaleta|Jef Spaleta]].
<references/>


[[DimiPaun|Dimi Paun]] expressed[4] frustration with what he charcaterized as "lame community involvenment" and several personal attacks were made on both the maintainer and other contributors who had deprecated the attempt to take a mailing list vote. After tempers had flared Jeff commented[5]: "Noone has figured out how to write a markup language for human intention...and as a result any passionate discussion degrades severely as we are wired to read intention but without body language and vocal ques...we absolutely do it wrong when relying solely on written language. Even more so with English! If we mandated everyone encode thought into Lisp we'd be having more constructive discussions (and less of them). The productivity of the list would be through the roof."
=== Is gNaughty a Hot Babe ? ===


In response to a challenge to detail some advantages of spatial-mode [[TomasTorcz|Tomas Torcz]] was among those who offered[6] that the persistent screen placement of directory windows was a major advantage. He also suggested a way to avoid leaving multiple windows open: "When I open new window and don't want parent directory open, I just open with middle button. Some people prefer Shift+click in this situation. I never has to use `Close all parent folder' (ctrlshift-w), but I aware it exist." [[JoonasSarajärvi|Joonas Sarajärvi]] confirmed[7] the persistence as an advantage: "[...] the state of each folder is persistent. Every window opens in the same view that it had when I reopen them. I can have appropriate zoom levels and views for every directory I commonly use."
[[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.  


Very much later in the thread, after he had been referred to several times, the package maintainer [[AlexanderLarsson|Alexander Larsson]] replied[8] that he was unconvinced both by the tone and content of the argument that there was a case to be made for changing the default.
One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"


It is possible to choose which behavior one wants by at least two methods. One can either use the <code>GUI</code>
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. 


<pre>Nautilus -> Preferences -> Behavior -> Always open in browser windows</pre>
<references/>


or else change the <code>GConf</code> setting using
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


<code>gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true</code>
[[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"


As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others [[MatthiasClasen|Matthias Clasen]] suggested[9] that anyone wishing to make permanent change to the default settings could create a <code>sabayon</code> profile.
[[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.  


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02089.html
<references/>


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02286.html
=== Who Wants a Pony? ===


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02305.html
[[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02416.html
<references/>


[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02392.html
=== Firestarter Retired as Unportable to PolicyKit ===


[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02387.html
[[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02213.html
Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>.
<references/>


[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02189.html
=== Russian Fedora ? ===


[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02389.html
When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem.


=== Font Package Naming Guidelines ===
An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]].


[[NicolasMailhot|Nicholas Mailhot]] ensured[1] that everyone was made aware of the new font package naming rules for <code>Fedora 11</code>. These will help break up large font packages in order to allow users to obtain fonts from desired families without imposing a large download burden.
<references/>


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02597.html
=== Will FESCo Revisit Kmods ? ===


=== How to become a Co-Maintainer ===
A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]].


[[RayVanDolson|Ray Van Dolson]] asked[1] for some information on identifying the current (co)maintainers of the <code>proftpd</code> package, the procedure to become a co-maintainer and the abilities to push bugfixes which this would confer upon him if the primary maintainer were absent.
[[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>.


A full answer was provided[2] by [[PatriceDumas|Patrice Dumas]] with links to <code>PackageDB</code> and the policies on the wiki regarding non-responsive maintainers.
<references/>


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02253.html
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02255.html
Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."


=== Proposed Package Re-Naming Guidelines ===
<references/>
 
Feedback was requested[1] by [[KevinFenzi|Kevin Fenzi]] on a draft guideline concerning the re-naming of packages either as a result of upstream action or locally to adhere to the [[NamingGuidelines]].
 
[[PatriceDumas|Patrice Dumas]] and [[DennisGilmore|Dennis Gilmore]] remembered[2] that a re-review followed by EOL of the old package was the current practice.
 
[[JasonTibbitts|Jason Tibbitts]][3] and [[JesseKeating|Jesse Keating]][4] referenced <code>IRC</code> discussions of the practice and its advantages in checking the <code>Obsoletes</code> and <code>Provides</code> in discussion with [[JochenSchmitt|Jochen Schmitt.]] Jochen was concerned[5] that the process be kept lightweight as opposed to a full review.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02052.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02054.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02058.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02056.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02060.html
 
=== Exiv2 Bump in Rawhide ===
 
[[RexDieter|Rex Dieter]] announced[1] that a bump to <code>exiv2-0.18</code>[2] would occur soon including a soname bump. [[JonCiesla|Jon Ciesla]] offered to help and Rex produced[3] a quick list of dependent applications.
 
When [[MatejCepl|Matej Cepl]] struggled with some odd results [[MichaelJChudobiak|Michael Chudobiak]] answered[4] that the API had changed a good deal.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02061.html
 
[2] Exiv is a command-line utility for examining EXIF and IPTC metadata of images.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02068.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02244.html
 
=== wxGTK2 to wxGTK Re-name ==
 
[[MichaelSchwendt|Michael Schwendt]] discovered[1] that a rename had been performed[2] some time ago so that there was no <code>wxGTK2-devel</code> package available. [[DanHorák|Dan Horák]] explained[3] that only <code>audacity</code> was affected. There was[4] some discussion about whether versioned <code>Provides</code> should be kept indefinitely.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01897.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01972.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01975.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02046.html
 
=== RFC: Description Text in Packages ===
 
Follow-up action (see FWN#153[1]) was requested[2] by [[RichardHughes|Richard Hughes]] for packagers to fix "isane descriptions" in their package summary text. <code>Enlightenment</code> was singled out as an example of an undesirable multi-page description. Richard also asked for comments on how bullet-points should be represented and the use of <code>UTF-8</code>.
 
A heated discussion followed[3] in which [[NicolasMailhot|Nicolas Mailhot]] deprecated the possible development of a "broken application-side transcoding system". He advocated the use of <code>UTF-8</code> over <code>ASCII</code> for several reasons including supporting the default Asian locales. Paragraph boundaries and lists were also mentioned[4] as a special area of concern.
 
This is a long and painful thread to read which expresses a conflict between constraints imposed by PackageKit and how things are currently done. Packagers should probably skim it to determine what final decisions are going to be made. [[RichardHughes|Richard Hughes]] seemed[5] to decide to implement what seemed to him to be sane changes to gnome-packagekit in which "If you're [g]oing to use [UTF-8 representations of skull-and-crossbones and radiation-hazard symbols] in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it."
 
 
[1] http://fedoraproject.org/wiki/FWN/Issue153#RFC:_Fix_Summary_Text_for_Lots_of_Packages
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01550.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01555.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01577.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01927.html

Latest revision as of 01:15, 1 June 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Would You Like to Write This Beat ?

Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.

  1. ↑ http://fedoraproject.org/wiki/FWN/WorkFlow
  2. ↑ http://fedoraproject.org/wiki/FWN/NewsProject/Join

Is gNaughty a Hot Babe ?

Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.

One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"

Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html
  2. ↑ One of the Common Lisp implementations: http://www.cons.org/cmucl/
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html
  9. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html

Chrome9 Vx800 Graphics Support on LiveUSB

Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"

Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html

Who Wants a Pony?

Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html
  2. ↑ http://bugzilla.redhat.com/show_bug.cgi?id=503021

Firestarter Retired as Unportable to PolicyKit

Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.

Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."

A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html
  2. ↑ Firestarter is a firewall configuration GUI
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html

Russian Fedora ?

When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.

An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html

Will FESCo Revisit Kmods ?

A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.

Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html

Upgrade from Fedora 10 to Rawhide (Fedora 11)

Following a report from Uwe Kiewel that a 

yum upgrade

had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=105137"