From Fedora Project Wiki

< FWN‎ | Beats

(177 devel beat pass1)
 
(9 intermediate revisions by the same user not shown)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== In a Flap Over Flags ===
=== Would You Like to Write This Beat ? ===


This week's "frank and open exchange of views" took the (non)inclusion of country flags as its subject. A reminder was posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01403.html</ref> by [[User:Kevin|Kevin Fenzi]] of a previous FESCo decision to split flags representing geopolitical or ethnocultural concepts into separate subpackages. [[User:Spot|Tom Callaway]] posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01427.html</ref> the history of how he had come to draft the proposal and noted that the inclusion of the Taiwan/Republic of China flag and possible consequences to the distributability of Fedora in the P.R.C. were the initial impetus. Upon request [[User:Jwboyer|Josh Boyer]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01670.html</ref> the relevant IRC log of the 2009-03-27 FESCo meeting.
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.


Lots of discussion was had in several separate threads. FESCo was criticized repeatedly for taking the decision.
<references/>


When Project Leader [[User:Pfrields|Paul W. Frields]] was pressed to comment he replied<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01480.html</ref> that it was not his job to interfere with FESCo decisions of this sort and that he agreed with [[DavidWoodhouse|David Woodhouse's]] take: namely, that while disapproving of censorship, there was precedent for removing material deemed likely to offend the sensibilities of some users.
=== Is gNaughty a Hot Babe ? ===


Although [[User:Notting|Bill Nottingham]] thought that it was absurd [[User:Toshio|Toshio Kuratomi]] and [[User:Skvidal|Seth Vidal]] explored<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01550.html</ref> some ideas about how <code>YUM</code> plugins and a new entry in the <code>Provides</code> namespace might enable a technical solution.
[[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.  


[[User:Jkeating|Jesse Keating]] outlined<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01582.html</ref> the advantages of a "no flags" policy in gaining possible contributors from the PRC and also getting wider exposure for software in RHEL.
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?"  


[[User:|Denis Leroy]] was a persistent critic of the decision and called<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01661.html</ref> for most of FESCo to resign.
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.
 
[[User:Pertusus|Patrice Dumas]] kicked off<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01557.html</ref> a fresh instance of the thread which recast the discussion in terms of two separate issues: legality and giving offense.
 
The original questions about the "No Flags" policy were posed<ref></ref> by [[User:Cwickert|Christoph Wickert]] and he started<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01740.html</ref> a fresh instance because: "The `Package Maintainers Flags policy" thread already counts more than 225 mails, but nobody bothered to answer 7 simple (?) questions I asked in my mail, although it was one of the very first three mails on the topic. So what did I do wrong? Was it that I mentioned the missing FESCo meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a fact worth mentioning.  I'm one of the few maintainers who directly is affected by the policy. Would somebody - preferably a FESCo member, who voted for the flags proposal - please be so kind to answer my questions. TIA!" [[User:Jwboyer|Josh Boyer]] answered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01743.html</ref> pretty thoroughly. He included the information that the policy would be revisited in the next meeting and an explanation that the FESCo meeting summaries were incomplete due to the failure of an attempt to rotate the onerous minute taking duties. [[User:Notting|Bill Nottingham]] added<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01892.html</ref> that the missing items should now be available.


<references/>


Yet a further thread was started<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01910.html</ref> by [[User:Mso|Martin Sourada]] as a proposal to create icon-themes as a long-term support solution.
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


The policy, as currently formulated is<ref>https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy</ref> posted on the wiki.
[[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?"


The 2009-05-22 FESCo meeting voted<ref></ref> to overturn the flag policy and to start gathering information on the actual scope of the problem. [[User:Kkofler|Kevin Kofler]] started<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01895.html</ref> a thread to this end.  
[[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.  


<references/>
<references/>


=== FESCo Election Questions ===
=== Who Wants a Pony? ===


[[User:Jstanley|John Stanley]] reminded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01735.html</ref> everyone that nominations for five FESCo seats are open until 2009-05-29 for "[a]ny interested Fedora packager [...] the only requirement is membership in the 'packager' group in FAS."
[[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.


Given the rumblings over the geopolitical flags issue (and other signs of discontent) it may be that this will be an interesting election.
<references/>


The requirement to be a packager was a new one and raised<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01756.html</ref> questions from [[User:Poelstra|John Poelstra]] and [[User:Sundaram|Rahul Sundaram]]. [[User:Jkeating|Jesse Keating]] argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01768.html</ref> that FESCo was "[...] primarily concerned with the packages and distribution release side of the house." This was disputed by several commenters who referenced decisions made by FESCo which affected documentation, artwork and internationalization.
=== Firestarter Retired as Unportable to PolicyKit ===


[[User:inode0|John Rose]] wanted to know why the voting-pool was not the same as the candidate-pool and [[User:Jwboyer|Josh Boyer]] responded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01796.html</ref> that the issue should be raised by filing a ticket with FESCo. [[AndreasThiemann|Andreas Thiemann]] and [[User:inode0|John Rose]] agreed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01879.html</ref> that there was a culture of meritocracy in the Fedora Project and [[User:inode0|John Rose]] observed that: "The Fedora Board and FESCo and others think of themselves as being part of a meritocracy (at least that is my perception of what they think) but at the same time are trying to encourage more widespread democratic participation which naturally runs counter to perpetuating the meritocracy."
[[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>.


A subsequent 2009-05-22 FESCo meeting addressed the issue of restricting its membership to packagers and ratified the current practice while leaving open the door for further discussion if need be. The meeting summary (posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01869.html</ref> by [[User:Notting|Bill Nottingham]]) noted that no one who lacked packager status had actually expressed interest in running.
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."
   
   
[[User:Knurd|Thorsten Leemhuis]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01507.html</ref> for participation in preparing questions to pose to the candidates once the nominations are closed.
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/>
<references/>


=== Anaconda vs YUM Upgrades ===
=== Russian Fedora ? ===


A brief thread initiated by [[User:Dtimms|David Timms]] explored<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01353.html</ref> why it has been easier to upgrade a system with <code>anaconda</code> rather than <code>YUM</code>. David referenced a suggestion that: "anaconda is cheating (ie running --nodeps installs). This would allow it to complete an upgrade where dependencies lead to unavailable packages that are not on the dvd, but are in the complete Fedora, and or non- fedora repositories, that are not available at upgrade time."
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.


[[User:Skvidal|Seth Vidal]] replied<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01360.html</ref> that as <code>anaconda</code> was running outside of the system experiencing the update it was free to use "--nodeps [without] a concern for not being able to complete the transaction." <code>Anaconda</code>'s ability to use blacklists to exclude particular items from such transactions is now available to <code>preupgrade</code> as a <code>YUM</code> plugin.
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]].


[[User:Katzj|Jeremy Katz]] added<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01386.html</ref> that: "It also means that we can do things like use a newer version of rpm or a new kernel with ext4 support to (eventually) allow for migrating from ext3->ext4[.]"
<references/>


 
=== Will FESCo Revisit Kmods ? ===


<references/>
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]].


=== Broken Dependencies in Fedora 12 Development ===
[[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>.


[[User:Mschwendt|Michael Schwendt]] posted three lists of broken dependencies in Fedora 12 development<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01866.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01867.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01868.html</ref>.
<references/>
<references/>


=== Too Many Conflicts ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


[[User:Mschwendt|Michael Schwendt]] reminded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01917.html</ref> the list that packagers were ignoring conflicts too readily.  
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."


<references/>
<references/>

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"