From Fedora Project Wiki

< FWN‎ | Beats

(fix missing refs)
 
(10 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
Contributing Writer: [[User:Ush|Oisin Feeley]]
 
Contributing Writer: [[User:Ush|Oisin Feeley]]
  
=== Broken Dependency Brouhaha ===
+
=== Would You Like to Write This Beat ? ===
  
The deliberate introduction of a broken dependency by [[RichardJones|Richard W.M. Jones]] resulted prolonged discussion and two FESCo discussion items tabled for the 2009-05-15 meeting. One of those items was the possible removal of "provenpackager" status from Richard.  
+
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.
  
[[User:Mschwendt|Michael Schwendt]] noticed<ref>https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696</ref> that an update for <code>libguestfs</code><ref>This exciting library's ability to perform modifications within virtual machine images without the need to actually run those images has been covered previously in the FWN virtualization beat</ref><ref>http://fedoraproject.org/wiki/FWN/Issue175#libguestfs_on_non-Fedora_Platforms</ref> had been pushed by developer [[RichardJones|Richard W.M. Jones]] in the full knowledge that <code>Fedora 10</code> users would need to import a <code>Fedora 11</code> <code>qemu</code> package. An anonymous comment on <code>Bodhi</code> situated the decision to release the update as an example of Richard not respecting the release process. Richard argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01084.html</ref> that as the <code>libguestfs</code> package was completely new only those aware of what they were doing would install it (and consequently would be aware that they needed the <code>qemu</code> from <code>Rawhide</code> or <code>Fedora 11</code>.)
+
<references/>
  
A strong reaction against "[c]reating broken deps when you know they won't be corrected[...]" ensued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01094.html</ref> and led<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01130.html</ref> to [[User:Skvidal|Seth Vidal]] deciding to question Richard's suitability as a "provenpackager" on the basis that he lacked common sense.
+
=== Is gNaughty a Hot Babe ? ===
  
A sidethread on the advantages of introducing dependency-checking was started by [[AdelGadllah|drago01]]. While [[User:Jwboyer|Josh Boyer]] agreed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01111.html</ref> that it would be useful he asked for help in solving the difficult problems which he listed.
+
[[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.  
  
The 2009-05-15 FESCo meeting resolved<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01320.html</ref> that [[User:Toshio|Toshio Kuratomi]] and [[RichardJones|Richard W.M. Jones]] should draft a [[Packaging/Guidelines|Packaging Guideline]] for approval by the [[Packaging/Committee|Fedora Packaging Committee]]. The meeting also decided that as Richard's introduction of a broken dependency was made in the absence of a clear prohibition against such actions, and he was clear that it would not recur, then no sanction should be taken. The handling of similar requests in the future were agreed to be best handled on a case-by-case basis.
+
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?"
 +
 
 +
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.
  
Richard added<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01087.html</ref> that the necessary back-porting of changes to <code>qemu</code> in <code>Fedora 10</code> were going to happen. Currently the update has been revoked.
 
 
 
<references/>
 
<references/>
  
=== Verilog Emacs Add-Ons ===
+
=== Chrome9 Vx800 Graphics Support on LiveUSB ===
  
The prime mover behind the Fedora Electronic Lab Spin, [[User:Chitlesh|Chitlesh Goorah]], asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01290.html</ref> for feedback on splitting-out "verilog-mode" into a separate package so that upstream changes could be tracked more rapidly. This would also have the benefit of laying the groundwork to support OVM and VMM (see FWN#161<ref>https://fedoraproject.org/wiki/FWN/Issue161#Electronic_Design_Automation_Content_Without_Tools_.3F</ref>).
+
[[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?"
  
[[JonathanUnderwood|Jonathan Underwood]] made<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01303.html</ref> some good points concerning the danger of missing out on emacs trunk integration of such packages if they were split out. He suggested instead: "[...] a packaging strategy whereby we don't rip out verilog-mode from the core emacs packages, but we can also have an add-on package which contains the latest and greatest verilog-mode which, if installed, is loaded in preference to the one from the core emacs packages[.]" This seemed to be accepted as a positive direction by Chitlesh and a review of the <code>emacs-verilog-mode</code> package was started<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01305.html</ref> by Jonathan.
+
[[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.  
 
 
[[JerryJames|Jerry James]] raised<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01316.html</ref> the issue of <code>XEmacs</code> also having its own version of the package, due to byte-code divergence between <code>Emacs</code> and <code>XEmacs</code>, and also some GPLv2 versus GPLv3 compatibility issues.
 
  
 
<references/>
 
<references/>
  
=== Open JDK7 Experimental Package ===
+
=== Who Wants a Pony? ===
 
 
[[LillianAngel|Lillian Angel]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01251.html</ref> where the <code>OpenJDK</code><ref>http://openjdk.java.net/</ref> team should post their unstable <code>java-1.7.0-openjdk</code> package: 1)to RPMFusion; 2) to a personal FedoraPeople page; 3) to the main Fedora repositories.
 
 
 
Lillian disliked the last option: "I am not keen on getting this package pushed into Fedora since java-1.6.0-openjdk already exists, and jdk7 will not be stable until sometime after Feb 2010<ref>http://openjdk.java.net/projects/jdk7/milestones/</ref>."
 
  
Following several suggestions it was decided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01264.html</ref> that a personal FedoraPeople repository was the best solution as there would be six or seven packages with no interdependencies.
+
[[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.
  
 
<references/>
 
<references/>
  
=== Making Noise About Moksha ===
+
=== Firestarter Retired as Unportable to PolicyKit ===
  
When [[DimiPaun|Dimi Paun]] continued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01003.html</ref> to report problems using PulseAudio (see FWN#<ref>http://fedoraproject.org/wiki/FWN/Issue174#PulseAudio_Flamewar_Continues</ref>) responses suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01005.html</ref> that his use of non-Free <code>Flash</code> or tweaking of <code>GStreamer</code> settings was responsible. Debugging using <code>gstreamer-properties</code> to ensure that "pulsesink" or "autoaudiosink" was the default sink was recommended<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01010.html</ref>.  
+
[[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>.
  
[[User:Lennart|Lennart Poettering]] wanted a bug filed instead of posts to @fedora-devel and when Dimi explained that <code>Bugzilla</code> was too slow and he had already spent a lot of time on the problem [[User:Sundaram|Rahul Sundaram]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01018.html</ref> using <code>Bugz</code> instead.
+
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/>
  
Criticism of the display of possibly thousands of "CLOSED" bugs by <code>Bugz</code> led [[User:Spot|Tom Callaway]] to offer<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01021.html</ref> the hope that <code>Fedora Community</code> will allow developers to "[...] show new/open packages only on a per package basis[.]" This occasioned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01022.html</ref> some apparent criticism from [[User:Sundaram|Rahul Sundaram]] of a lack of openness "[...] it is a giant silo [...]" around the development of <code>Fedora Community</code><ref>https://fedorahosted.org/fedoracommunity/</ref>. [[User:Spot|Tom Callaway]] offered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01029.html</ref> a list of resources to contradict this. When Rahul returned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01030.html</ref> with the criticism that there "[...]is definitely a big lack of communication on this development with the rest of the Fedora community.  There was a very brief mail to fedora-announce list but how much input are you getting input from Fedora maintainers whose job this is supposed to make easier?" there was a distinct lack of enthusiasm for more aggressive marketing. [[User:Jwboyer|Josh Boyer]] reaffirmed the involvement of several developers with large package lists and expressed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01051.html</ref> a fear that bike-shedding would result from any more exposure.  [[User:Pfrields|Paul W. Frields]] pointed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01059.html</ref> to a useful interview<ref>https://fedoraproject.org/wiki/Moksha_in_Fedora_11</ref> with [[User:Lmacken|Luke Macken]] about the <code>Moksha</code> web-application framework upon which <code>Fedora Community</code> is being built. 
+
=== Russian Fedora ? ===
  
<code>Moksha</code> is built on a collection of python-based web-frameworks and uses <code>Orbited</code> instead of <code>AJAX</code> to connect rich web applications to servers. Reportedly this is more responsive than AJAX techniques.  
+
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.
  
A test instance of <code>Fedora Community</code> and <code>AJAX</code> was reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01132.html</ref> by [[User:Spot|Tom Callaway]] to be up. He emphasized that it was a test instance, currently not to be relied upon at all and a disinclination "[...] to spend time wading through the `OMG THIS IS SLOWER THAN BUGZLILLA!!!1!'" reports.
+
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]].
  
 
<references/>
 
<references/>
  
=== Be Excellent to Each Other ===
+
=== Will FESCo Revisit Kmods ? ===
  
Regular readers are no doubt aware that flamewars have become more common on @fedora-devel. Project Leader [[User:Pfrields|Paul W. Frields]] posted<ref>https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00026.html</ref> to the @fedora-advisory-board that the FAB<ref>http://fedoraproject.org/wiki/Board</ref> had decided to deal with the "[...] degradation in tone and signal [...]" by appointing moderators.  
+
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]].
  
[[User:Mmcgrath|Mike McGrath]] worried<ref>https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00031.html</ref> that this would constitute an extra burden for board members and also objected to any censorship on principal. [User:Mmcloughlin|Mark McLoughlin]] wondered how posters warned privately by moderators that their behavior was problematic could defend themselves. [[User:Skvidal|Seth Vidal]] replied<ref>https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00059.html</ref> that this was not a court of law and that problems with moderators could be reported to the board. Later posts along these lines drew<ref>https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00072.html</ref> a response from [[LuisVilla|Luis Villa]] which argued strongly that over valuing one's own liberty was a problem: "Or to put it another way: The Fedora community exists to work together towards some common goals. Sometimes, in the name of reaching those goals, you have to be polite and adult towards others so that you can work efficiently and constructively with those other people even when you disagree with them, and work with them in the future after you have stopped disagreeing. This use of words like 'freedom' and 'oppression' suggests to me that some people think their highest reason for being here is about them. It's not about you, it's about working together to build something bigger and better than you. And if you can't play nicely with others in the name of those bigger and better things, or don't understand why sometimes you have to play nice in order to get to those bigger and better things, then maybe this isn't the right place for you."
+
[[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:Pfrields|Paul W. Frields]] reported<ref>https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00043.html</ref> that a good deal of work led by [[User:Kevin|Kevin Fenzi]] was going on to moderate the IRC channels. A later post made<ref>https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00052.html</ref> by [[MaxSpevack|Max Spevack]] referenced IRC bans in the #cobbler channel and suggested that Red Hat employees needed to be tough-minded and hold themselves to higher standards than other contributors.  
 
  
 
<references/>
 
<references/>
  
=== Best Way to Store Information Across Desktops ===
+
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
 
[[User:Kushal|Kushal Das]] requested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00901.html</ref> tips on making a truly cross-desktop application.
 
  
[[User:Adamwill|Adam Williamson]] noticed that many applications were storing information in <code>~/.config</code> files and [[User:bochecha|Mathieu Bridon]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01009.html</ref> the information that this was an <code>XDG</code><ref>http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html</ref> spec from freedesktop.org which resulted in replacing a plethora of <code>.app</code> directories with only two: <code>.config</code> to store configuration and <code>.local/share/</code> to store data.
+
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."
  
[[JaroslavReznik|Jaroslav Řezník]] pointed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00966.html</ref> to work by the KWallet and gnome-keyring developers to develop<ref>https://bugs.freedesktop.org/show_bug.cgi?id=16581</ref> a single-sign-on solution on top of a <code>DBUS</code>-based protocol.
 
 
 
 
<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.

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.

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.

Who Wants a Pony?

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

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.

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.

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.

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."