From Fedora Project Wiki

< FWN‎ | Beats

(add useful JeremyKatz quote)
 
(37 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]]


=== GSoC InstantMirror ===
=== Would You Like to Write This Beat ? ===


[[WarrenTogami|Warren Togami]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00873.html</ref> for any interested parties to get involved with a GSoC<ref>http://code.google.com/soc/</ref> project to improve repository replication to mirrors.
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.


<references/>
<references/>


=== Enhance Anaconda to Enable Repositories As Needed ? ===
=== Is gNaughty a Hot Babe ? ===


[[JudCraft|Jud Craft]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00921.html</ref> that installing from the <code>Fedora 10</code> DVD with the <code>fedora-updates</code> repository enabled resulted in a broken <code>NetworkManager</code> due to a missing dependency on <code>libudev.so.0</code>. Jud pointed out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00929.html</ref> that although he could install the missing library from the DVD the situation would present a serious problem to anyone that tried "[...] a network install with updates [...] the result (a system without network access) can't be fixed without A) network access, or B) another Fedora image (also possibly requiring more network access)."
[[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.  


In answer to [[User:Jspaleta|Jef Spaleta's]] questions Jud revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00938.html</ref> that: "[libudev.so.0] doesn't seem to actually be installed by the stock F10 image.  If I do a plain install (no updates), NetworkManager works fine.  Running a `yum update' then pulls down all the updates, as well as `Install libudev0'.  So at some point I suppose NetworkManager picked up a dependency on libudev0, but for some reason updating during the installation process doesn't pull this new package in." [[User:Kkofler|Kevin Kofler]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00944.html</ref> and [[User:Jkeating|Jesse Keating]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00947.html</ref> both pointed out that: "[T]he updates repo isn't the Everything repo. To really do a proper install with updates you have to enable both the Updates repo and the Everything repo." Kevin added that this was why the install from DVD with updates enabled was not an officially supported method.
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?"  


Several people, including [[User:Thl|Thorsten Leemhuis]], suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00953.html</ref> that modifying the <code>anaconda</code> installer to be aware of which repositories depend on each other would be useful. [[User:Jkeating|Jesse Keating]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00955.html</ref> not averse to the idea as long as it could be done in a "[...] distro agnostic way. Avoiding hardcoded hacks specifically for Fedora is one of the goals of anaconda upstream."
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.
 
Later [[User:Katzj|Jeremy Katz]] explained<ref>http://://www.redhat.com/archives/fedora-devel-list/2009-March/msg00976.html</ref> that the thinking behind the installer ignoring unsatisfiable dependencies in such cases is to "[...] get someone installed and then let them clean up afterwards[.]"


<references/>
<references/>


=== Password Resets and Inactive Accounts ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===
 
When [[User:Mmcgrath|Mike McGrath]] was perturbed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00509.html</ref> that so many FAS account holders had failed to reset their passwords recently a discussion of the entanglement of active account status and passwords followed.
 
Many respondents posted that they had received the email notifications but had not needed to, or had not had time to, perform their password reset.


[[http://bugzilla.fedora.us/wiki/TomLane Tom Lane]] worried that forcing periodic password resets caused people to weaken security by writing down their passwords but [[User:Bruno|Bruno Wolf III]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00612.html</ref> that a potentially bigger threat might be "[...] someone forging messages from Mike with deceptive URLs that trick people into changing their passwords using a hostile proxy. Doing things in the current manner is training people to get fooled." He added that cryptographically signing the reset messages was important.
[[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:Till|Till Maas]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00710.html</ref> consistent titling of the password reset notification emails, suggested extending the grace period beyond two weeks and asked that the notification contains the information that the contents of the user's fedorapeople.org home would be moved.
[[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.  
 
[[User:Mmcgrath|Mike McGrath]] and others explored<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00779.html</ref> possible grace periods and numbers of warning emails.
 
[[User:Pertusus|Patrice Dumas]] asked why there was a password reset at all and was answered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00658.html</ref> by [[User:Jkeating|Jesse Keating]] that it was "[...] the best way Infra has today to discover all the active and inactive accounts." In response [[User:Toshio|Toshio Kuratomi]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00677.html</ref> to an open ticket which nominally deals with how long accounts should be left open if passwords have expired but had become<ref>http://fedorahosted.org/fedora-infrastructure/ticket/1237</ref> an investigation of how account inactivity can be determined.
 
After [[User:Mmcgrath|Mike McGrath]] explained that "[...] we've got thousands of contributors, relatively few of them actually commit to cvs.  So we could go around to figure out how to make all of our various auth points report back but that's a lot of work.  The account system is the only common point of entry for every contributor [...]" [[ChristopherAillon|Christopher Aillon]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00812.html</ref>: "So let's require to them to simply _log in_ to FAS to reset the timer (you need to do that to change passwords, anyway!)."


<references/>
<references/>


=== Mono Conflagration Jumps to Blog ===
=== Who Wants a Pony? ===
 
Following the FESCo decision not to replace <code>rhythmbox</code> with <code>banshee</code> as the default media-player in <code>Fedora 11</code><ref>http://fedoraproject.org/wiki/FWN/Issue166#Fedora_11_Default_Mediaplayer_Not_Banshee._Mono_to_Blame_.3F</ref> some follow-up clarifications were made by parties to the discussion and the conflagration jumped between @fedora-devel and the personal blog of [[User:Dnielsen|David Nielsen]], the <code>Banshee</code> ex-maintainer and perhaps the main force behind the Mono SIG<ref>http://fedoraproject.org/wiki/SIGs/Mono</ref>.
 
[[User:Notting|Bill Nottingham]] put forward<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00529.html</ref> a concise time-line which attempted to show that the proposal had been handled in a straightforward and usual manner. Bill noted that the Desktop SIG had expressed<ref>http://www.redhat.com/archives/fedora-desktop-list/2009-February/msg00063.html</ref> a lack of enthusiasm early in the process and that the imminent beta-freeze meant that the decision had to be taken without further prolonged discussion.
 
[[User:Adamwill|AdamWilliamson]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00526.html</ref> that because <code>Mono</code>'s Microsoft links worried many F/OSS developers it would have been a good idea to address such concerns: "[...] explicitly rather than just pretend they don't exist in your initial proposal (the word 'Mono' does not actually occur a single time in the initial version of the Wiki page you posted)."
 
A question put by [[User:Johannbg|Jóhann B. Guðmundsson]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00523.html</ref> whether there was anything preventing the Mono SIG from creating their own Fedora spin in which <code>banshee</code> was given pride of place as the default media-player. [[User:Rdieter|Rex Dieter]] confirmed that there were no obstacles on this path.


A proposal to adopt a Code of Conduct modeled upon Ubuntu's was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00498.html</ref> made by [[RichardJones|Richard W.M. Jones]]. He also expressed regret that David was leaving Fedora and apparently moving to <code>Ubuntu</code> as referenced<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/</ref> by a blog entry. Reading the blog suggest that <code>Foresight Linux</code> seems more to David's taste although one comment does point out<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/#comment-285</ref> that Ubuntu "[...] head community people have been calling for volunteers to increase the work surrounding Mono and have a huge love for banshee<ref>http://castrojo.wordpress.com/2009/01/11/monodevelop-rockstar-needed-inquire-within/</ref> and Canonical isn’t anti-mono since some of their new job postings desire Mono as a skill<ref>http://webapps.ubuntu.com/employment/canonical_GDOS/</ref>."
[[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.
 
[[User:Skvidal|Seth Vidal]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00504.html</ref> among those who wondered specifically how such a code could be enforced and also where specifically the Fedora Project could be alleged to have engaged in misconduct on this issue. Reading David's blog seems to suggest both that any rudeness was privately exchanged and that his perception is<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/#comment-297</ref> that "[...] Mono isn't welcome in Fedora, and will always be a second class citizen[.]"


<references/>
<references/>


=== Documentation Betas ===
=== Firestarter Retired as Unportable to PolicyKit ===


[[User:Jjmcd|John J. McDonough]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00835.html</ref> that owners of major features should review the Beta release notes. [[ScottRadvan|Scott Radvan]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00823.html</ref> that the Security Guide<ref>http://sradvan.fedorapeople.org/Security_Guide/en-US/</ref> would benefit from the scrutiny of any interested @fedora-devel readers.
[[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>.


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


=== Provenpackager Re-Seed ===
=== Russian Fedora ? ===


[[User:Jstanley|Jon Stanley]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00555.html</ref> that everyone read the process by which the "provenpackager" group will be repopulated.
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 request by [[RalfCorsepius|Ralf Corsepius]] for some definitions led [[User:Pertusus|Patrice Dumas]] to post<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00571.html</ref> that: "provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora." Further discussion led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00581.html</ref> [[User:Mschwendt|Michael Schwendt]] to voice a concern that non-responsive maintainers might be shielded from feedback if provenpackagers step in to update and upgrade packages. [[User:Kkofler|Kevin Kofler]] offered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00718.html</ref> the non-responsive maintainer process as a way to rectify any problems with Bugzilla tickets being ignored.
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:Mschwendt|Michael Schwendt]] questioned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00591.html</ref> [[User:Pertusus|Patrice Dumas]] in greater detail as to why provenpackagers and sponsors are not equal sets.
Further details on how to apply to FESCo to become a provenpackager were elicited<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00594.html</ref> from [[User:Jwboyer|JoshBoyer]] by [[StepanKaspal|Stepan Kaspal]].
In a separate thread MichelSalim asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00871.html</ref> about the preferred way to become a sponsor.
<references/>
<references/>


=== Closing Bugs NEXTRELEASE ===
=== Will FESCo Revisit Kmods ? ===


[[User:Cwickert|Christoph Wickert]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00552.html</ref> that all maintainers (and especially Red Hat developers) would "[p]lease fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!"
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]].


When [[User:Sundaram|Rahul Sundaram]] responded that it depended on the seriousness of the bug and complexity of back-porting [[DanielBerrange|Daniel P. Berrange]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00575.html</ref> and [[User:Rakesh|Rakesh Pandit]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00572.html</ref> acknowledged that such complex cases might exist but that suggested that this was often a cop-out which could discourage users.
[[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:Katzj|Jeremy Katz]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00622.html</ref> "[...] as the person who has apparently pissed you off this morning [...]" and described the case in point as much more complex than Christoph had claimed. It seemed that Christoph's ability to create <code>LiveCD</code> images of <code>Fedora 11</code> using <code>Fedora 10</code> as the development platform had been stymied by changes to <code>syslinux</code>. Jeremy added that even if this single change were reverted Christoph would need a newer <code>kernel</code> and <code>squashfs-tools</code> and more.
<references/>


Later Jeremy clarified<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00777.html</ref> that the combination of <code>livecd-creator</code> + <code>mock</code> were complicated by <code>SELinux</code> but that this had been addressed by recent work.
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


One complication is that <code>Bodhi</code> uses NEXTRELEASE even for updates to stable releases. After some confusion on this point LukeMacken posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00672.html</ref> that anyone wanting to change the behavior should file a ticket.
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.

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