From Fedora Project Wiki

< FWN‎ | Beats

(#166 devel beat, spellchecked, fasnames checked. 6 topics)
 
(42 intermediate revisions by the same user not shown)
Line 2: Line 2:
== Developments ==
== Developments ==


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


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


=== Orphans Purged ===
=== Would You Like to Write This Beat ? ===


It sounded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00093.html</ref> like Dickensian cruelty when [[User:Jkeating|Jesse Keating]] announced that he would be purging the orphans. All that it meant however was that those packages which were not blocked and had no owners would be "[...] blocked, and will not be shipped with F11." The initial list mistakenly listed <code>EPEL</code> packages and a shorter revised list was posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00103.html</ref>.
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.
 
A follow-up posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00474.html</ref> states that packages listed therein will be removed on 2009-03-09 unless volunteers are found to maintain them.


<references/>
<references/>


=== Fedora 11 to Ship Tiger VNC ===
=== Is gNaughty a Hot Babe ? ===
 
[[AdamTkac|Adam Tkac]] wrote<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00213.html</ref> to explain why he had decided "one minute before the beta freeze" to replace <code>TightVNC</code> with the <code>TigerVNC</code> fork. Adam has a history of very actively seeking to merge improvements upstream which in the past led<ref>http://fedoraproject.org/wiki/FWN/Issue119#Baracuda_To_Replace_VNC_.3F</ref> to the replacement of <code>RealVNC</code> with <code>TightVNC</code> when it seemed that the latter was more willing to evolve. The glacial pace of <code>RealVNC</code> development seemed to be correlated with the presence of a non-Free enterprise edition. Adam reported that unfortunately a lack of co-ordination of the <code>TightVNC</code> project had led to the <code>TurboVNC</code> and <code>TightVNC</code> projects deciding that a fork was necessary. An initial mail posted<ref>http://sourceforge.net/mailarchive/forum.php?thread_name=alpine.LFD.2.00.0902271116020.25749%40maggie.lkpg.cendio.se&forum_name=tigervnc-users</ref> by PeterÅstrand on @tigervnc-users provides some more details.


One specific outcome anticipated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00217.html</ref> by KingInuYasha was a "[...] proper implementations of VNC 4 for UNIX like systems [...] Having a VNC implementation that actually is kept up to date with the VNC protocol and is optimized with extensions is something I have been waiting for awhile now."
[[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.  


Another hint of good things which may come from a more rapid pace of development was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00221.html</ref> when Daniel Berrange asked about Adam's plans to include the <code>VeNCrypt</code> server-side SSL/TLS extension. This would result in a "[...] consistent TLS extension that's inter operable across all the VNC clients & servers in Fedora." Daniel also mentioned that he had "[...] recently defined & implemented another VNC auth extension based on SASL. This provides for a good extendable authentication capability, most importantly including GSSAPI Kerberos for single sign on. I've got it implemented for QEMU, KVM, GTK-VNC and VINO already, so again it'd be good to plan for adding it to TigerVNC too so we have a widely interoperable strong authentication system."
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?"  


All in all it looks as though contrary to their slogan "The VNC that bites" TigerVNC will be superb.
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.


<references/>
<references/>


=== Ready for a New RPM Version ? ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


On 2009-02-26 [[PanuMatilainen|Panu Matilainen]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02117.html</ref> if it would be possible to introduce <code>RPM-4.7</code> at this late stage of the <code>Fedora 11</code> release cycle. This new version decreases memory use and improves performance. Panu emphasized that it was not as large an upgrade as the "[...] 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year [.]"
[[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?"


[[User:Notting|Bill Nottingham]] was among those who expressed concern that <code>rpm-4.7</code> would be completely ready for the final release of <code>Fedora 11</code>. He also wondered if there would be incompatibilities with previous <code>rpm</code> version. Panu answered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02161.html</ref> that <code>rpm-4.7</code> was expected to be ready for the final release and that incompatibilities would only result if packagers used the <code>POSIX</code> file capabilities. This latter is protected against with an <code>rpmlib()</code> dependency.
[[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.  


A certain amount of disquiet at the idea of "[g]oing with a beta version of critical infrastructure like RPM [...]" based on the recent changes to RPM was voiced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02134.html</ref> by [[TomLane|Tom Lane]]. Upon a challenge from [[User:Skvidal|Seth Vidal]] some problems with the process of upgrading <code>rpm</code> to handle stronger hashes were listed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02142.html</ref> by [[User:Notting|Bill Nottingham]]. These included including "No solution for handling packages natively on F9" and [[TomLane|Tom Lane]] expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02146.html</ref> on the point: "I'm personally still ticked off that I'm being forced to update my development workstation to F-10 immediately in order to continue doing useful work on rawhide packages.  I don't have time for that right now.  Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?" The general response seemed to be that developers need to use one of the virtual machine solutions in order to be able to build for <code>rawhide</code>.
<references/>


A substantial sub-thread on the rate of change in <code>rawhide</code> and whether or not developers should use it or stick to the current stable release with a virtualized instance of <code>rawhide</code> developed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02213.html</ref> following some thoughts from [[User:Adamwill|Adam Williamson]].
=== Who Wants a Pony? ===


[[User:Sundaram|RahulSundaram]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02156.html</ref> for more information on the use of <code>LZMA</code> compression as this is one of the new features of <code>rpm-4.7</code>. Panu replied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02173.html</ref> <code>LZMA</code> will not be used by default as it would make even the current <code>Fedora 10</code> <code>rpm</code> unable to read packages produced with such compression.
[[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.
 
A FESCo decision made on 2009-03-06 confirmed<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-06.html</ref> that <code>rpm-4.7</code> would be the version shipping in <code>Fedora 11</code>.


<references/>
<references/>


=== Windows Cross-compiler Added to comps.xml ===
=== Firestarter Retired as Unportable to PolicyKit ===


Following from a FESCo 2009-03-06 decision [[RichardJones|Richard W.M. Jones]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00365.html</ref> to add a "Windows cross-compiler" group to <code>comps.xml</code> before the rapidly approaching 2009-03-10 string freeze.
[[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:Kkofler|Kevin Kofler]] asked why Richard did not call it "MinGW cross compiler" and Richard responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00384.html</ref> that he wanted to avoid trademarks and leave open the possibility to broaden support to other non-embedded platforms. He came up with either "Consumer cross-compilers (CCC) or Consumer cross-compiler collection (CCCC)." Kevin had some other interesting questions about the legality of possible <code>OS X</code> cross-compilers and the desirability of one group per OS. Richard pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html</ref> to an earlier thread on the latter question.
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/>


=== Anaconda Default of Separate / and /home Partitions ===
=== Russian Fedora ? ===


A long-standing bugzilla entry was referenced<ref></ref> by Lex Hider as background for the idea that <code>anaconda</code> should support separate <code>/home</code> and <code>/</code> partitions in order to support clean installs during upgrades. Lex's detailed post included links to relevant previous discussion.
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:Adamwill|Adam Williamson]] was very much in favor of the idea and in response to [[User:Jkeating|Jesse Keating]] suggested<ref></ref> some heuristics which might allow <code>anaconda</code> to determine the relative sizes of the <code>/</code> and <code>/home</code> partitions. [[User:Bruno|Bruno Wolff III's]] <code>/</code> partition size (circa 40GB) proved<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01976.html</ref> to be surprisingly large due to multiple languages installed. [[MichelSalim|Michel Salim]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02167.html</ref> and [[CallumLerwick|Callum Lerwick]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02021.html</ref> both brought up the necessity to have a large <code>/</code> partition in order to be able to run <code>preupgrade</code>.
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]].
 
Lex elaborated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02356.html</ref> on possible space requirements for such a scheme.


<references/>
<references/>


=== Beta Freeze and String Freeze this Tuesday 2009-03-10 ===
=== Will FESCo Revisit Kmods ? ===


[[User:Ausil|Dennis Gilmore]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00430.html</ref> a heads up on 2009-03-06 that "[...] anything that needs translations needs to be done by COB [Tuesday]. This is a blocking Freeze any packages you need included in the Beta release must be requested via release engineering [.]"
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]].


A brief amount of confusion occurred<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00425.html</ref> due to the misnaming of the day of the week.  [[User:Till|Till Maas]] also wondered exactly what Close Of Business meant exactly for an international project like <code>Fedora</code>.
[[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>.


<references/>
<references/>


=== Fedora 11 Default Mediaplayer Not Banshee. Mono to Blame ? ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


A summary of FESCo deliberations posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00417.html</ref> by BillNottingham stirred DavidNielsen to object that he had not been alerted (as maintainer) that discussion of the <code>Banshee</code> media player was to occur. David also objected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00426.html</ref> that the onus had been placed on him to convince the maintainer of the competitor <code>Rhythmbox</code> package to allow the replacement. He also suggested that the use of the <code>Mono</code> language was a stumbling block due to <code>RHEL</code> eschewing <code>Mono</code>: "[...] RHEL does not ship Mono, if RHEL wants to ship Rhythmbox that is their decision but what Fedora ships should not be. What else are we going to be dictated from above.. who else should bother to make proposals for what they preceive to be improvements?"
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."


[[User:Jkeating|Jesse Keating]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00428.html</ref> that his understanding was that the desire to avoid <code>mono</code> in <code>Fedora</code> is to avoid bloating the <code>LiveCD</code>s with dependencies. The IRC logs bore out<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-06.html</ref> this interpretation with FESCo members explicitly stating that "[...] what its written in should have no bearing on what goes in[.]" It was also clear however that <code>RHEL</code>, as the largest downstream distributor of an OS directly derived from <code>Fedora</code>, would not be ignored.
<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"