From Fedora Project Wiki

< FWN‎ | Beats

m (→‎RawERhide ?: add missing ref)
(176 pass1. fasnames checked)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Presto A-Go-Go ! ===
=== Broken Dependency Brouhaha ===


Thanks to some hard work by Fedora Infrastructure folk [[User:Lmacken|Luke Macken]], [[User:Skvidal|Seth Vidal]], [[User:Notting|Bill Nottingham]] and [[User:Jwboyer|Josh Boyer]] <code>Fedora 11</code> will<ref>http://jwboyer.livejournal.com/31831.html</ref> come Presto-enabled contrary to last week's gloomy forecast<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Presto_No_Go</ref>.  
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.  


[[User:Pfrields|Paul W. Frields]] described the potential saved download bandwidth as "[t]ypically [...] in double digits, but I’ve heard of cases already (using our development branch Rawhide) where people were saving 90% or more of their download time."
[[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></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>.)


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


=== PPC as a Secondary Architecture ===
=== Verilog Emacs Add-Ons ===
 
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>).


The 2009-05-07 FESCo summary reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00581.html</ref> that there is interest in moving PowerPC to secondary architecture status. [[DavidWoodhouse|David Woodhouse]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00614.html</ref> that it would be interesting to hear from existing secondary architecture teams on the problems they had experienced. To date there are no secondary architectures ready to ship in Fedora.
[[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.
 
[[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/>


=== Retiring Packages ===
=== Open JDK7 Experimental Package ===


The decision of the 2009-05-07 FESCo meeting to orphan packages from de-activated maintainers led<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00596.html</ref> [[User:Toshio|Toshio Kuratomi]] to advertise that <code>PackageDB</code> will soon be able to retire packages.
[[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.


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


=== RawERhide ? ===
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:Jkeating|Jesse Keating]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00359.html</ref>: "How is it we have 182 stable updates pending for F11 already?  How have these seen any testing by a wider audience?  Are we really just not bothering with updates-testing anymore?  Do we not care about distro stability?" An interesting thread discussed the ways in which developer workflow and the availability of updates for testing can be re-aligned to each other. Among the complications discussed were the need to provide a way to upgrade for a previous release and the coupling of DVD image preparation with a release.
<references/>


[[User:Till|Till Maas]] replied that updates-testing requests for <code>Fedora 11</code> had apparently not been processed and [[User:Kkofler|Kevin Kofler]] argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00573.html</ref> that the chances were high that packages which built succesfully on an earlier release would build on a later one. This was disputed by [[User:Jkeating|Jesse Keating]]. [[User:Dcantrel|David Cantrell]] and [[User:Skvidal|Seth Vidal]] shared<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00382.html</ref> their experience of users not responding to requests to test and comment on updates provided in <code>Bodhi</code>.
=== Making Noise About Moksha ===


A debate over the problems caused between the mismatch between the rolling, continuous nature of development and the need to freeze packages in a known state to produce a release received substantial contributions from [[RalfCorsepius|Ralf Corsepius]], who argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00435.html</ref> that Release-Engineering should change the workflow considerably. [[User:Jkeating|Jesse Keating]] responded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00469.html</ref> with a defense of the current system which emphasized the need of maintainers to adhere to the current workflow and "good development practices."
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></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>.  


[[RichardJones|Richard W.M. Jones]] was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00398.html</ref> in favor of rolling releases.
[[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.


[[User:Mschwendt|Michael Schwendt]] explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00554.html</ref> the problems arising when the <code>updates-testing</code> repository was not used as intended.
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.


[[MichalHlavinka|Michal Hlavinka]] proposed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00448.html</ref> breaking the freeze solely for the updates-testing repository shortly before the GA release.
<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.  


There's a lot more in this thread beyond the ability of your correspondent to summarize adequately. It's worth a read for anyone trying to understand how and why Fedora is produced.
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.


<references/>
<references/>


=== Crypto Consolidation ===
=== Be Excellent to Each Other ===
 
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></ref> had decided to deal with the "[...] degradation in tone and signal [...]" by appointing moderators.


[[AdamGoode|Adam Goode]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00349.html</ref> whether <code>NSS</code> was ready to provide <code>TLS</code> support. Adam referenced the Crypto Consolidation project<ref>http://fedoraproject.org/wiki/FedoraCryptoConsolidation</ref> (see also FWN#107<ref>http://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation</ref>).
[[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."


[[Dwinship|Dan Winship]] confirmed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00370.html</ref> that for the present <code>NSS</code> was best used directly with applications rather than by other libraries. [[RobertRelyea|Robert Relyea]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00493.html</ref> a detailed response to Adam including the hopeful sounding news that some of the issues around <code>NSS_Init</code> may be fixed in a few months.
[[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/>


=== Intel Moblin Pushing Proprietary Poulsbo ? ===
=== Best Way to Store Information Across Desktops ===


Last week's thread<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Moblin2_Mostly_Fedora-derived_.3F</ref> about the significant amount of Fedora-originating code being rolled into Intel's <code>Moblin2</code> platform without much kudos or thanks continued. Questions were asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00212.html</ref> about why Intel was not providing code for the <code>Poulsbo</code> graphics chipset (common in many netbooks) except via obscure repositories.  The appearance of ex-Red Hatter [[ArjanvandeVen|Arjan van de Ven]], who argued in defense of binary blobs in these drivers, occasioned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00248.html</ref> some wry commentary.
[[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.  


When [[User:Adamwill|Adam Williamson]] pointed to a "huge new pile of crack [...] in the Ubuntu Mobile special-sauce repositories [...]" [[DanWiliams|Dan Williams]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00326.html</ref>: "What makes the Poulsbo team so special that they are exempt from the upstreaming policy that every other part of Intel seems to follow so well these days?" Later discussion suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00491.html</ref> that it ought to at least be possible to produce a "[...] basic native accelerated 2D driver which doesn't depend on all the horrible proprietary crack [.]"
[[User:Adamwill|Adam Williamson]] noticed that many applications were storing information in <code>~/.config</code> files and [[User:bochecha|Mathieu Bridon]] provided<ref></ref> the information that this was an <code>XDG</code><ref></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.


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

Revision as of 19:10, 17 May 2009

Developments

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

Contributing Writer: Oisin Feeley

Broken Dependency Brouhaha

The deliberate introduction of a broken dependency by 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.

Michael Schwendt noticed[1] that an update for libguestfs</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>[2] had been pushed by developer Richard W.M. Jones in the full knowledge that Fedora 10 users would need to import a Fedora 11 qemu package. An anonymous comment on Bodhi situated the decision to release the update as an example of Richard not respecting the release process. Richard arguedCite error: Invalid <ref> tag; refs with no name must have content that as the libguestfs package was completely new only those aware of what they were doing would install it (and consequently would be aware that they needed the qemu from Rawhide or Fedora 11.)

A strong reaction against "[c]reating broken deps when you know they won't be corrected[...]" ensued[3] and led[4] to Seth Vidal deciding to question Richard's suitability as a "provenpackager" on the basis that he lacked common sense.

A sidethread on the advantages of introducing dependency-checking was started by drago01. While Josh Boyer agreed[5] that it would be useful he asked for help in solving the difficult problems which he listed.

The 2009-05-15 FESCo meeting resolved[6] that Toshio Kuratomi and Richard W.M. Jones should draft a Packaging Guideline for approval by the 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.

Verilog Emacs Add-Ons

The prime mover behind the Fedora Electronic Lab Spin, Chitlesh Goorah, asked[1] 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[2]).

Jonathan Underwood made[3] 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 emacs-verilog-mode package was started[4] by Jonathan.

Jerry James raised[5] the issue of XEmacs also having its own version of the package, due to byte-code divergence between Emacs and XEmacs, and also some GPLv2 versus GPLv3 compatibility issues.

Open JDK7 Experimental Package

Lillian Angel asked[1] where the OpenJDK[2] team should post their unstable java-1.7.0-openjdk 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[3]."

Following several suggestions it was decided[4] that a personal FedoraPeople repository was the best solution as there would be six or seven packages with no interdependencies.

Making Noise About Moksha

When Dimi Paun continued[1] to report problems using PulseAudio (see FWN#Cite error: Invalid <ref> tag; refs with no name must have content) responses suggested[2] that his use of non-Free Flash or tweaking of GStreamer settings was responsible. Debugging using gstreamer-properties to ensure that "pulsesink" or "autoaudiosink" was the default sink was recommended[3].

Lennart Poettering wanted a bug filed instead of posts to @fedora-devel and when Dimi explained that Bugzilla was too slow and he had already spent a lot of time on the problem Rahul Sundaram suggested[4] using Bugz instead.

Criticism of the display of possibly thousands of "CLOSED" bugs by Bugz led Tom Callaway to offer[5] the hope that Fedora Community will allow developers to "[...] show new/open packages only on a per package basis[.]" This occasioned[6] some apparent criticism from Rahul Sundaram of a lack of openness "[...] it is a giant silo [...]" around the development of Fedora Community[7]. Tom Callaway offered[8] a list of resources to contradict this. When Rahul returned[9] 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. Josh Boyer reaffirmed the involvement of several developers with large package lists and expressed[10] a fear that bike-shedding would result from any more exposure. Paul W. Frields pointed[11] to a useful interview[12] with Luke Macken about the Moksha web-application framework upon which Fedora Community is being built.

Moksha is built on a collection of python-based web-frameworks and uses Orbited instead of AJAX to connect rich web applications to servers. Reportedly this is more responsive than AJAX techniques.

A test instance of Fedora Community and AJAX was reported[13] by 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.

Be Excellent to Each Other

Regular readers are no doubt aware that flamewars have become more common on @fedora-devel. Project Leader Paul W. Frields posted[1] to the @fedora-advisory-board that the FABCite error: Invalid <ref> tag; refs with no name must have content had decided to deal with the "[...] degradation in tone and signal [...]" by appointing moderators.

Mike McGrath worried[2] 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. Seth Vidal replied[3] 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[4] a response from 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."

Paul W. Frields reported[5] that a good deal of work led by Kevin Fenzi was going on to moderate the IRC channels. A later post made[6] by 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.

Best Way to Store Information Across Desktops

Kushal Das requested[1] tips on making a truly cross-desktop application.

Adam Williamson noticed that many applications were storing information in ~/.config files and Mathieu Bridon providedCite error: Invalid <ref> tag; refs with no name must have content the information that this was an XDGCite error: Invalid <ref> tag; refs with no name must have content spec from freedesktop.org which resulted in replacing a plethora of .app directories with only two: .config to store configuration and .local/share/ to store data.

Jaroslav Řezník pointed[2] to work by the KWallet and gnome-keyring developers to develop[3] a single-sign-on solution on top of a DBUS-based protocol.