From Fedora Project Wiki


Revision as of 00:54, 25 May 2009 by Ush (talk | contribs) (FWN 177 todate: Planet, QA, Devlopment, Art, Comic, SecurityWeek,)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Planet Fedora

In this section, we cover the highlights of Planet Fedora[1] - an aggregation of blogs from Fedora contributors worldwide.

Contributing Writer: Adam Batkin


Michael DeHaan wrote[1] an essay "Recognizing and Avoiding Common Open Source Community Pitfalls" such as that "contributors appear overnight out of the woodwork, that users grow on trees, and that it’s possible to direct community members as if they were employees."

Thorsten Leemhuis asked[2]: "What questions would you like to ask the Fedora Board or FESCo Candidates?" for the upcoming Fedora Board and FESCo elections. "Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help*"

Richard W.M. Jones announced[3] the first proper version of virt-inspector, "a command line tool that tells you what’s in a virtual machine. You just point it at a disk image or a libvirt domain" and it can discover a number of pieces of information about the installed VM.

Thomas Canniot posted[4] a How-To about running a successful release event. "Fedora 11 is going to be released at the end of the month and very soon, our massive army of ambassadors will want to spread how proud they are of their Fedora 11 release to the masses."

Jef Spaleta calculated[5] new Fedora usage statistics that combined the Smolt and MirrorManager logs to come up with some very interesting new numbers.

Paul W. Frields responded[6] to the recent discussions about the new fedora-devel moderation policy. "There’s simply no place in free software, and certainly not in Fedora, for that kind of abuse. Of course harsh words aren’t the end of the world. When we let them become the noise that drowns out the signal, though, we’re putting the project at risk. If contributors feel their time in community discussions are wasted, they will either hold them elsewhere, or simply go away."

Jack Aboutboul interviewed[7] Lennart Poettering ("Red Hat Desktop Team Engineer and resident audio guru") about Pulse Audio and audio in Fedora.

Susan Lauber wrote[8] about "how can you - a Fedora contributor - assist in making the wiki more useful for everyone?" For anyone wondering how they can start contributing to Fedora, this is a great way to start, without any long-term commitments.

Nicu Buceli reported[9] from eLiberatica 2009[10] in Bucharest, Romania.

Jeff Sheltren discussed[11] "Why Students should get Involved in Open Source". Jeff says that "from my experience, open source experience has given our student employees an enormous boost when looking for their first jobs out of college."

Adam Williamson mentioned[12] the Common F11 bugs wiki page, and how you can help: "It’s really easy - everything you need to know to add an issue to the Common Bugs page is right there in the page source, as a comment. If you edit the page you’ll see a few chunks of comments which explain how to add an issue (including a template entry), and what else to do when adding one..." James Laska also suggested[13] that there are still some high priority defects that could use some extra testing in preparation for the imminent Fedora 11 release.

Thorsten Leemhuis explained[14] that "There is one small change in Fedora 11 that I guess will confuse Fedora and RPM Fusion users with x86-32 (aka i386/ix86) systems quite a lot, but afaics did not get enough attention yet: By default, the PAE kernel will be used on 32-bit hardware, where appropriate."


In this section, we cover the activities of the QA team[1].

Contributing Writer: Adam Williamson

Test Days

There was no Test Day last week, as we are deep in the Fedora 11 final release run-up.

Currently, no Test Day is scheduled for next week - it is too close to the scheduled release of Fedora 11 for any testing to produce results directly in Fedora 11 final release, but if you would like to propose a test day which could result in changes for post-release updates, or an early test day for Fedora 12, please contact the QA team via email or IRC.

Weekly meetings

The QA group weekly meeting[1] was held on 2009-05-20. The full log is available[2]. Adam Williamson reported that he had filed a ticket to have Bodhi use the appropriate resolution for bugs fixed with stable release updates. Luke Macken said he would take care of the ticket. Adam also reported that he had not yet remembered to ask the Bugzilla team to add a link to the Fedora bug workflow page.

James Laska reported that he had not yet sent out a Test Day feedback survey to previous participants, but had a draft ready and would continue to work on it.

John Poelstra said that he had not yet finalized a schedule for blocker bug reviews during the Fedora 12 cycle, as the overall Fedora 12 cycle was still not finalized. He will revisit the issue next week.

Will Woods reported there had been little work on the autoqa project or adding upgrade test cases to the Wiki during the week, as testing for Fedora 11 release had taken priority.

The group discussed the Fedora 11 release situation, and noted that the release had been pushed back one week. They examined the blocker bug list, and found it was generally manageable. Francois Cami noted that major fixes to's core or the ATI driver were unlikely as Dave Airlie is on vacation. The group noted that most remaining blockers were in the Intel driver, and assigned to

The group then discussed the Fedora 11 Common Bugs page[3]. Adam Williamson volunteered to revise the existing page to match the format used for previous releases, initiate a few other changes based on his previous work on Mandriva Linux Errata pages, and talk to other groups about the use of the page, including the Documentation group, and the IRC, mailing list and forum support teams. Francois Cami volunteered to help ensure all appropriate issues are tracked on the page.

In open discussion, Francois Cami noted that for Fedora 11, users of several generations of ATI Radeon cards would now only have the free drivers as a viable choice, whereas previously they would be able to use the ATI proprietary driver from third-party repositories. It was also noted that, at release time, the commonly-used RPMFusion repository would have no packages available for the proprietary driver even for cards for which it is still available, due to the lack of a reliable patch for kernel 2.6.29. The group discussed whether this could be explained in the release notes (with no definite resolution, but advice to check with the Documentation team), and how to note the requirements for a full and useful bug report for problems with the free driver from such users. Adam Williamson noted that the appropriate venue for such information would be the Bugs and Feature Requests Wiki page[4].

The Bugzappers group weekly meeting[5] was held on 2009-05-19. The full log is available[6]. John Poelstra reported on progress of the housekeeping changes for Fedora 11's release, and the group agreed that he was doing a fine job and should keep it up.

Adam Williamson reported on the progress of the triage metric system. Brennan Ashton has again been busy (and without access to a regular internet connection), so progress has been slow. Adam clarified that the main choke point now was the lack of a set of test data for the scripts, to ensure that they were working correctly, and explained he was doing his best to get this data made available. Once it is available, work on the system is no longer solely dependent on Brennan being available.

Adam Williamson also reported on the progress of the proposal to include setting the priority / severity fields as part of triage. He had sent out the mail asking for feedback on how to proceed, but had received none yet. The group agreed that he should send out another mail as a new thread, and set a deadline of the end of the week; if no significant feedback to the contrary was received by that point, the group agreed they should proceed using the method proposed by Matej Cepl.

The next QA weekly meeting will be held on 2009-05-27 at 1600 UTC in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-05-26 at 1500 UTC in #fedora-meeting.

Blocker bug review meeting

John Poelstra announced[1] a joint QA / Release Engineering Fedora 11 blocker bug review meeting on Friday 2009-05-22. The meeting was not logged, but all outstanding release blockers were reviewed, some were closed or downgraded, and action plans were decided for several.

Adobe Flash installation instructions

Christopher Beland explained[1] that he had updated the Wiki page on Flash[2] with the latest instructions on installing it on x86-64 systems. Adam Williamson noted[3] that the page should emphasize free software alternatives as well as the proprietary Adobe Flash system. Paul Frields announced[4] that he had made such a change.

Fedora 11 Common Bugs page

Adam Williamson announced[1] his revisions to the Fedora 11 Common Bugs page, and asked the group to contribute to expanding and maintaining the page and consistently refer to it when explaining problems. He also explained some of the planned improvements to the content of the page and its interaction with Bugzilla.

Mozilla / Beagle blocker bug proposal

Jonathan Kamens asked[1] whether a bug preventing Beagle from searching Mozilla Firefox and Thunderbird data should be a release blocker, on the basis that desktop search is a key function for some users and web browser and email data are important sets which someone may wish to search. Brian Pepple pointed out[2] that it did not meet the official release blocker criteria[3], but Jonathan responded that the page admits this is a subjective judgment, and many bugs that do not strictly meet those criteria are in fact considered blockers. In the end, it was mostly agreed that, because Beagle is not installed by default and so is not considered core functionality, the issue should not be considered a blocker.

New Bugzappers

Two new Bugzappers volunteers introduced themselves this week: Xia Shing Zee[1] and Alex Turner[2].


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.

Christoph Wickert started[9] a fresh instance of the thread because: "[t]he `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 voted[14] to overturn the flag policy and to start gathering information on the actual scope of the problem. Kevin Kofler started[15] 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.


In this section, we cover the Fedora Artwork Project[1].

Contributing Writer: Nicu Buculei

Goodbye Fedora-art, Welcome Fedora-design

Máirín Duffy announced[1] a major rebranding: "we are going to rebrand ourselves as the Fedora Design team rather than the Fedora Art team, both in hopes of attracting more UX designers, and also since it's a more accurate representation of the team so folks needing help with UI design will know where to go." The change involves modification in the mailing list, IRC channel, the Fedora Account System and awesome new functionality, shared file storage "This means rather than painfully uploading your work file-by-file to the wiki, you can just drag and drop files in batches to the shared directory and link to the top level or individual files from the wiki [...] This way, other folks on the design team can collaborate and upload their improvements and remixes to the same place so we don't have files for the same project all over the place."

Statistics Poster

Steven Moix asked[1] of @fedora-design about an updated statistic poster[2] "Could someone have a look at the Statistics Poster to update it to 4F standards and update it with recent statistics?", request quickly accomplished[3]Paul Frields "It was very easy to do, thanks to the way it was created -- whoever you are, thank you very much!" (as discovered later[4], it was developed by Dimitris Glezos and Máirín Duffy)

Fedora Weekly Webcomic


Nicu's latest and last webcomic[1]

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers

Cloudy Trust? has a nice article that points out some of the probably flaws in cloud computing: Cloud Security: Danger (and Opportunity) Ahead. [1] In theory, cloud computing is a fine idea that has the potential to lower the cost of a CPU cycle dramatically. The thing nobody is really talking about yet is keeping your data secure. Right now, it would be rather unwise to presume that anything you send to the cloud won't be compromised in some way. Securing a highly multi-user environment such as this is going to pose a huge challenge. Problems nobody has even though of are going to emerge, and will take a great deal of cooperation and understanding to solve them. This is one of the places that Open Source style collaboration will prove to be highly useful.