From Fedora Project Wiki

< FWN‎ | Beats

(fix missing refs)
(177 devel beat pass1)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Broken Dependency Brouhaha ===
=== In a Flap Over Flags ===


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


[[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>.)
Lots of discussion was had in several separate threads. FESCo was criticized repeatedly for taking the decision.  


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


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


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


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.
[[User:|Denis Leroy]] was a persistent critic of the decision and called<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01661.html</ref> for most of FESCo to resign.
<references/>


=== Verilog Emacs Add-Ons ===
[[User:Pertusus|Patrice Dumas]] kicked off<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01557.html</ref> a fresh instance of the thread which recast the discussion in terms of two separate issues: legality and giving offense.


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


[[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.
Yet a further thread was started<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01910.html</ref> by [[User:Mso|Martin Sourada]] as a proposal to create icon-themes as a long-term support solution.


<references/>
The policy, as currently formulated is<ref>https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy</ref> posted on the wiki.


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


[[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>."
===  FESCo Election Questions ===


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


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


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


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


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


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


<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.
=== Anaconda vs YUM Upgrades ===


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


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


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


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.
 


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


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


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


=== Best Way to Store Information Across Desktops ===
=== Too Many Conflicts ===


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


[[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.
[[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 00:30, 25 May 2009

Developments

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

Contributing Writer: Oisin Feeley

In a Flap Over Flags

This week's "frank and open exchange of views" took the (non)inclusion of country flags as its subject. A reminder was posted[1] by Kevin Fenzi of a previous FESCo decision to split flags representing geopolitical or ethnocultural concepts into separate subpackages. Tom Callaway posted[2] the history of how he had come to draft the proposal and noted that the inclusion of the Taiwan/Republic of China flag and possible consequences to the distributability of Fedora in the P.R.C. were the initial impetus. Upon request Josh Boyer provided[3] the relevant IRC log of the 2009-03-27 FESCo meeting.

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

When Project Leader Paul W. Frields was pressed to comment he replied[4] that it was not his job to interfere with FESCo decisions of this sort and that he agreed with David Woodhouse's take: namely, that while disapproving of censorship, there was precedent for removing material deemed likely to offend the sensibilities of some users.

Although Bill Nottingham thought that it was absurd Toshio Kuratomi and Seth Vidal explored[5] some ideas about how YUM plugins and a new entry in the Provides namespace might enable a technical solution.

Jesse Keating outlined[6] the advantages of a "no flags" policy in gaining possible contributors from the PRC and also getting wider exposure for software in RHEL.

[[User:|Denis Leroy]] was a persistent critic of the decision and called[7] for most of FESCo to resign.

Patrice Dumas kicked off[8] a fresh instance of the thread which recast the discussion in terms of two separate issues: legality and giving offense.

The original questions about the "No Flags" policy were posedCite error: Invalid <ref> tag; refs with no name must have content by Christoph Wickert and he started[9] a fresh instance because: "The `Package Maintainers Flags policy" thread already counts more than 225 mails, but nobody bothered to answer 7 simple (?) questions I asked in my mail, although it was one of the very first three mails on the topic. So what did I do wrong? Was it that I mentioned the missing FESCo meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a fact worth mentioning. I'm one of the few maintainers who directly is affected by the policy. Would somebody - preferably a FESCo member, who voted for the flags proposal - please be so kind to answer my questions. TIA!" Josh Boyer answered[10] pretty thoroughly. He included the information that the policy would be revisited in the next meeting and an explanation that the FESCo meeting summaries were incomplete due to the failure of an attempt to rotate the onerous minute taking duties. Bill Nottingham added[11] that the missing items should now be available.


Yet a further thread was started[12] by Martin Sourada as a proposal to create icon-themes as a long-term support solution.

The policy, as currently formulated is[13] posted on the wiki.

The 2009-05-22 FESCo meeting votedCite error: Invalid <ref> tag; refs with no name must have content to overturn the flag policy and to start gathering information on the actual scope of the problem. Kevin Kofler started[14] a thread to this end.

FESCo Election Questions

John Stanley reminded[1] everyone that nominations for five FESCo seats are open until 2009-05-29 for "[a]ny interested Fedora packager [...] the only requirement is membership in the 'packager' group in FAS."

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

The requirement to be a packager was a new one and raised[2] questions from John Poelstra and Rahul Sundaram. Jesse Keating argued[3] that FESCo was "[...] primarily concerned with the packages and distribution release side of the house." This was disputed by several commenters who referenced decisions made by FESCo which affected documentation, artwork and internationalization.

John Rose wanted to know why the voting-pool was not the same as the candidate-pool and Josh Boyer responded[4] that the issue should be raised by filing a ticket with FESCo. Andreas Thiemann and John Rose agreed[5] that there was a culture of meritocracy in the Fedora Project and John Rose observed that: "The Fedora Board and FESCo and others think of themselves as being part of a meritocracy (at least that is my perception of what they think) but at the same time are trying to encourage more widespread democratic participation which naturally runs counter to perpetuating the meritocracy."

A subsequent 2009-05-22 FESCo meeting addressed the issue of restricting its membership to packagers and ratified the current practice while leaving open the door for further discussion if need be. The meeting summary (posted[6] by Bill Nottingham) noted that no one who lacked packager status had actually expressed interest in running.

Thorsten Leemhuis asked[7] for participation in preparing questions to pose to the candidates once the nominations are closed.

Anaconda vs YUM Upgrades

A brief thread initiated by David Timms explored[1] why it has been easier to upgrade a system with anaconda rather than YUM. David referenced a suggestion that: "anaconda is cheating (ie running --nodeps installs). This would allow it to complete an upgrade where dependencies lead to unavailable packages that are not on the dvd, but are in the complete Fedora, and or non- fedora repositories, that are not available at upgrade time."

Seth Vidal replied[2] that as anaconda was running outside of the system experiencing the update it was free to use "--nodeps [without] a concern for not being able to complete the transaction." Anaconda's ability to use blacklists to exclude particular items from such transactions is now available to preupgrade as a YUM plugin.

Jeremy Katz added[3] that: "It also means that we can do things like use a newer version of rpm or a new kernel with ext4 support to (eventually) allow for migrating from ext3->ext4[.]"


Broken Dependencies in Fedora 12 Development

Michael Schwendt posted three lists of broken dependencies in Fedora 12 development[1][2][3].

Too Many Conflicts

Michael Schwendt reminded[1] the list that packagers were ignoring conflicts too readily.