From Fedora Project Wiki

< FWN

fp-wiki>ImportUser
(Imported from MoinMoin)
 
m (1 revision(s))
(No difference)

Revision as of 16:28, 24 May 2008

Fedora Weekly News Issue 90

Welcome to Fedora Weekly News Issue 90[1] for the week of May 27th through June 2nd, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3] .

[1] http://fedoraproject.org/wiki/FWN/Issue90

[2] http://fedoraproject.org/wiki/FWN/LatestIssue

[3] http://feeds.feedburner.com/fwn


Announcements

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

Announcing Fedora 7 (Moonshine)

The Fedora Project announces in fedora-announce-list[1] ,

"Fedora 7 is the first release where the development was one hundred and one per-cent in the community. How? It's simple, cousin -- all the code was merged into a single external repository. Why? Same great distribution quality, even more high-quality developers able to work directly with the code and improve the flavor of over 7500 packages."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00009.html

Freshrpms for Fedora 7

MatthiasSaou announces in fedora-announce-list[1] ,

"All freshrpms add-on packages are now available for Fedora 7."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00011.html

ATrpms for Fedora 7

AxelThimm announces in fedora-announce-list[1] ,

"ATrpms is officially launching Fedora 7 support for i386, x86_64 and ppc."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00010.html

A Few Words About Fedora 7

MaxSpevack announces in fedora-announce-list[1] ,

"Before I talk about Fedora 7, it's useful to look at recent history. One of the Fedora Project's mottos is "the rapid progress of free and open source software." With Fedora Core 5 in March of 2006, Fedora Core 6 in October of 2006, and Fedora 7 today, that's about 7 months per release. And with several million Fedora Core 6 installs, everyone who works on Fedora should feel very proud that not only is the software being released often, but it's also high quality, and in high use around the world."

"Fedora 7 represents the culmination of several goals that Fedora has spent the last few releases (spanning the course of at least 2 years) working to achieve. I've written previously on this list about the aspects of Fedora 7 that I think are the most important[2] ."

"From my perspective, it is the fundamental infrastructure changes that Fedora 7 represents that are the biggest achievement. The entire Fedora toolchain has been freed. Every step in the distribution-building process is completely open."

"And I speak for everyone at Red Hat when I say that it is an honor to be a part of something like Fedora. Congratulations to everyone on today's release."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00008.html

[2] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00002.html

Discounts on Red Hat training for Fedora folks

MaxSpevack announces in fedora-announce-list[1] ,

"The nature of Fedora is such that many of our contributors and users are very technical, and make Linux their careers as well as their hobbies. We know that many Fedora contributors and users hold RHCT, RHCE, or RHCA certifications. Obviously, we are happy that you choose Red Hat Training and and we appreciate your business. As a way of saying thank you to our community, we are pleased to offer special discounts[2] to Fedora contributors who register for upcoming Red Hat training courses."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00000.html

[2] https://www.redhat.com/training/fedora_training_discount.html

Planet Fedora

In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.

http://fedoraproject.org/wiki/Planet

Contributing Writers: ThomasChung, KarstenWade

Fedora is now an open source project

ChristopherBlizzard points out in his blog[1] ,

"But of course, these are not the most important qualities of Fedora 7. The qualities that I’m interested in are somewhat intangible. What this release represents is a first step down a long path. Fedora is no longer something that just Red Hat produces. Those of us who work for the company have been long since eclipsed by the sheer number of people involved in Fedora from outside of the corporate firewall. It’s simple: Fedora is now an open source project. What’s interesting to me is how long we’ve been able to say this - a few months at best - but the number of people that have shown up who show a unique passion for the success of the project is just amazing. For a good view of some of them check out the Fedora Award Winners for 2007[2] . Every one of those guys just showed up and started making a difference."

[1] http://www.0xdeadbeef.com/weblog/?p=293

[2] http://www.redhatmagazine.com/2007/05/31/announcing-the-fedora-award-winners-for-2007/

Interview of Max Spevack

KushalDas points out in his blog[1] ,

"Yesterday night, I did a video interview of MaxSpevack (Fedora Project Leader). In this interview, he mostly talked about the upcoming Fedora-7 release, which will happen tomorrow. The plus points for the users. He also described the future targets of the Fedora project. You can see the interview here[2] . In the google video also at here[3] ."

[1] http://kushaldas.in/?p=134

[2] http://www.archive.org/details/InterviewOfMax

[3] http://video.google.com/videoplay?docid=-4461571891690806161&hl=en

UPDATE: Here is another Video Interview[1] of MaxSpevack (Fedora Project Leader) & Kital

[1] http://kushaldas.in/?p=145

Interview of Mike McGrath

KushalDas points out in his blog[1] ,

"As Fedora-7 is out for almost 1 day, I did an interview of MikeMcGrath (Fedora Infrastructure). He talked about how it went :)" You can see it here[2] .

[1] http://kushaldas.in/?p=136

[2] http://video.google.com/videoplay?docid=7800949146474110046&hl=en

Kernel hacking for laptops

RichardHughes reflects on his day off hacking the kernel in his blog[1] ,

"I've just posted a patch to fix the toshiba_acpi kernel driver to emit INPUT events when the fn hotkeys are pressed. This means that the hardware works out of the box, and integrates nicely with KDE and GNOME without using oddball uinput-injecting system daemons such as FnFX to do the userspace polling. This also obsoletes my hal addon to do basically the same thing."

[1] http://hughsient.livejournal.com/27324.html

fedoraproject.org promos

In response to a collaborative idea to do rotating banner promos on fedoraproject.org[1] , MairinDuffy posted a few ideas in her blog,

"So we've had this idea the past few days that now we have a new fedoraproject.org, we could do cool stuffs like have promos to highlight events, groups, and other cool stuff around Fedora.

The first promo we're thinking about is to highlight spins - the fact you can now create your own custom Fedora spins or highlight a particular spin."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00001.html

[2] http://mihmo.livejournal.com/41166.html

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

Some comments on Fedora 7

RahulSundaram reports in fedora-marketing-list[1] ,

"Fedora 7, the latest and arguably most ambitious release from the increasingly community-friendly Fedora Project, will hit the download mirrors later this week. With its installable live CDs, merged package repositories and much improved artwork, the new Fedora should prove a major attraction on the 2nd quarter release calendar[2] ."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00082.html

[2] http://distrowatch.com/weekly.php?issue=20070528

Fedora 7 "Moonshine": Freedom vs. Ease-of-Use (Part 1)

MarcWiriadisastra quoted an article in fedora-marketing-list[1] , which sparked a thread about how well Fedora explains its positions on IP-encumbered software.

"Fedora 7, a.k.a. "Moonshine," released on May 31, is an odd duck. On the one hand, it's hugely popular. If you need to be convinced of that, take a look at the number of people viewing the officially-sanctioned FedoraForum.org[2] at any given time - as I write this, it's almost 7,000 people. Visit your local Barnes & Noble Booksellers (that's a big bookstore chain in the U.S.) and you'll see quite a few books about Fedora on the shelves. (This, by itself, is a big plus for Linux newbies — Fedora may be the best-documented distro available)."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00021.html

[2] http://forums.fedoraforum.org/

Editor's Note: As of June 3, 2007, there were over 93,000 members in FedoraForum.org

Developments

In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.

http://www.redhat.com/mailman/listinfo/fedora-devel-list

Contributing Writer: OisinFeeley

OCaml Packaging

As previously reported[1] , the packaging of the OCaml language has been initiated. RichardJones wondered[2] whether his OCaml packages could be discussed at the upcoming FESCo meeting. Richard had discussed[3] some issues with ToshioKuratomi on @fedora-packaging but sought wider input.

[1] http://fedoraproject.org/wiki/FWN/Issue86#head-45f52ddea0d1c89a1e166a721b43fc10126dd37f

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02005.html

[3] https://www.redhat.com/archives/fedora-packaging/2007-May/msg00207.html

TomCallaway (spot) thought[4] that the discussion would be more appropriate to the packaging committee (which would be meeting within a week), while BrianPepple noted[5] that FESCo was open to anyone in the community who was willing to follow the basic etiquette.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02006.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02009.html

Fedora Secondary Architectures Proposal

A draft proposal on the support of different machine architectures was submitted[1] by TomCallaway for consideration. It resulted in prolonged and apparently unresolved disagreements. The proposal recognised two layers of architecture: Tier 1, consisting of x86 and x86_64; Tier2 consisting of SPARC, Alpha, PPC{,64}, IA64 (and possibly s390). Support of Tier1 would be considered the primary responsibility of the Fedora Project, while responsibility for the secondary architectures would be devolved onto volunteer teams (ArchTeams).

The buildsystem would be structured so that the failure of packages to build on Tier1 would prevent the packages from being pushed to the repository, but failure on Tier2 would not prevent the packages being pushed to the repository.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01862.html

The main points of contention seemed to arise from the possibility of disturbance of a currently well-working system by which package maintainers provide a certain amount of feedback to the existing Tier2 architectures. Balanced against that is the desire to allow niche-architecture interest groups to use the Fedora Project buildsystem, without causing undue potential disturbance to the majority of users.

An initial objection[2] from DavidWoodhouse (the driving force behind PPC support in Fedora) was that the proposed system would promote silent failures, a step backwards from the useful information now provided by maintainers through the required filing of a tracker bug each time "ExcludeArch:" is used in a package's specfile. JefSpaleta[3] and HasdeGoede[4] agreed with David on the advantages of the documentary nature of the current procedure. Jef proposed that the current ExcludeArch practice be extended to Tier2.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01863.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01865.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01893.html

Tom cautioned[5] that Jef's suggestion of ignoring failed builds would necessitate changes to Koji and would also probably result in frustrated package maintainers overusing ExcludeArch as soon as more Tier2 were added. David picked up[6] on this point and suggested that Tom and he were addressing different problems, with Tom considering the process of introducing a new architecture, while David himself was talking about the procedure to be followed during the ongoing attempt to support a Tier2, which had already had low-level stuff like glibc and gcc bootstrapped. David further suggested the idea[7] of allowing a maintainer to file a bug after a package failed to build for a particular architecture, but thought that this resulted in increased complexity for no gain. BillNottingham pointed out[8] that the gain was that Tier2 failures wouldn't hold up Tier1 package building and propagation even if the relevant ArchTeam failed to do a good job. ChrisBlizzard had separately indicated[9] that he estimated that inside of Red Hat they were "spending 50% of your time on 3% of your user base" and that the proposal avoided the delays in development which Fedora would also surely see if new architectures were added without this proposal being implemented.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01877.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01896.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01896.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02002.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02020.html

JesseKeating contradicted[10] the idea that Tier2 build failures would be "silent" and restated the proposal's central advantage in avoiding development delays due solely to Tier2 architectures. DavidWoodhouse disputed[11] the idea that progress would be hindered and itemized the reasons for which a package might cease to build succesfully, arguing that these were either easily within a package maintainer's abilities, or else could be passed on to the ArchTeam by filing an ExcludeArch bug. David further argued that the only downside might be a small delay resulting from putting a fixed package through the buildsystem again. Jesse referenced his personal experience in which he had seen packages sit unbuildable for hours and days due specialists on particular architectures being unavailable. Jesse also suggested that package maintainers would be overwhelmed by the additional work required, a point that was reinforced[12] by ChrisWeyl who was concerned at the signs of stress already emanating from package maintainers due to the Core/Extras merge. DaveJones substantiated[13] Jesse's evaluation of significant delays, citing 6 hours increased wait time as a result of having to resubmit to the build system. David thought that the i386 kernel build could be pushed anyway, and ChristopherAillon explained[14] that currently that couldn't happen because it would lead to inconsistencies in the primary repositories. Christopher also thought that there would be advantages for Red Hat in being able to treat the s390 architecture in this way.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01922.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01944.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01959.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02155.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02173.html

ChrisWeyl argued[15] that David's primary objection was about relaxing the requirement that maintainers be responsible for all architectures, but this had to be done in order to allow new architectures into the build system. TomCallaway thought[16] that Chris had appreciated the heart of his proposal. David replied[17] that the proposal seemed to be trying to solve a problem that didn't exist and that the current system was fine and did exactly what Chris said the new one should do. JakubJelinek emphasized[18] the problem of slow build times on particular architectures, providing specific information about the PPC{,64} builds and wondered whether asynchronous builds should be considered. OliverFalk was concerned[19] about addressing this problem for the Alpha architecture.

[15] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01871.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01872.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01895.html

[18] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01897.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01899.html

Responding to Jakub's data, David agreed[20] that slow builds for particular architectures was the only possible problem solved by the proposal and wished that TomCallaway had stated the problem more clearly. ChristopherAillon cited[21] the undesirability of delaying a critical Firefox security fix in order to add an ExcludeArch and then rebuild. He also mentioned the undesirability of waiting while exotic compiler bugs were fixed for Tier2 architectures (something which Firefox apparently exposes due to its complexity). David questioned[22] whether it would really take much time. Christopher responded[23] that it did (worst case of up to 9 hours) and added that the situation was complicated by the frequent bundling of multiple fixes in one shot. David dismissed this as an "esoteric" case and asked if it would be covered by just filing an ExcludeArch retrospectively, which Christopher assented[24] to, noting that this was what the proposal addressed. ChrisBlizzard ratified [24a] ChristopherAillon's experience, to which David responded that he'd been paid to do it.

[20] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01895.html

[21] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01933.html

[22] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01945.html

[23] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01967.html

[24] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01970.html

[24a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02029.html

JesseKeating did not agree[25] that retrospective ExcludeArch bug-filing would solve Christopher's case, because if a build were allowed to fail for a Tier2 case then it would fail for everything, necessitating a complete rebuild. This led to David clarifying[26] what he was proposing, which led Jesse to wonder why David was objecting to implementing the proposed steps automatically and TomCallaway expressed concern that it would be difficult to code correctly and suggested an alternate logical build path. David reiterated his objection[27] to breaking the current balance of work shared by package maintainers and others.

[25] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01971.html

[26] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01990.html

[27] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02053.html

Further discussion of Christopher's concrete example was mainly an exchange between David and Jesse. David argued[28] [29] against the "package monkey" approach of automatically filing ExcludeArch bugs and Jesse arguing[30] that maintainers couldn't reasonably be expected to do more than was suggested by the proposal if many new architectures were added. A lengthy, slightly circular and bad-tempered exchange developed with David arguing that incompetent Quality Assurance practices were being pursued and Jesse deciding that he'd had enough argumentation[31] .

[28] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01952.html

[29] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01969.html

[30] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01972.html

[31] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02075.html

OliverFalk tried to salvage[32] something positive from the discussion by proposing a categorization of the ways in which builds could fail. David largely agreed with him and pointed out his own earlier similar attempt. Oliver excused the duplication on the basis of not having read the lengthy thread.

[32] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02078.html

One repeated question that kept cropping up in these sub-threads was restated by ChrisBlizzard[33] , namely the question of what a package maintainer could reasonably be expected to do. DavidWoodhouse clove[34] to his earlier stated position in previous discussions that package maintainers could and should be expected to reach a high standard and that the current system worked well. ChristopherAillon suggested[35] that auto-filing of bugs could have a positive effect. BillNottingham thought[36] that the issue was more that the community was being asked to support the CPU fetishes of a minority user base, and that while the Fedora Project could offer facilities to such groups it shouldn't allow them to impede Fedora's primary mandate.

[33] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02023.html

[34] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02066.html

[35] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02084.html

[36] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02003.html

BillNottingham[37] , DennisGilmore[38] , and OliverFalk[39] raised the logistical issues of where the machines for these builds would be located. Bill noted that the file space was just not available at the moment. JesseKeating emphasized[40] that Red Hat shouldn't be looked to as the source of hardware, which should instead come from any interested community, even so OliverFalk seemed to have some good leads on mothballed Alphas!

[37] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01883.html

[38] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01884.html

[39] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01901.html

[40] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01940.html

Five Months To Fedora 8: A Conspiracy Against KDE?

Discussion of the next release of Fedora was initiated[1] by KevinKofler on the premise that it was a problem because it would exclude the final KDE4 by a mere six days. JesseKeating[2] replied that a stable schedule was more important than any one piece of software and would allow upstream projects to target Fedora more easily. Kevin wondered[3] why the relationship should work in that direction and noted that Fedora 8 would have to ship a release candidate of a very important KDE and that schedules slipped anyway. ChristopherAillon responded[4] that this frequently happened with GNOME, while JefSpaleta described[5] advantages of sticking to schedules.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02102.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02104.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02106.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02106.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02119.html

Kevin expressed[6] a belief that the release date was being done to suit GNOME at KDE's expense. ArthurPemberton noted that he'd heard this but asked for actual evidence, while SethVidal bluntly contradicted[7] the idea, saying that it was in order to not lose development staff during the winter holidays.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02111.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02132.html

DavidWoodhouse acknowleged that schedules were good but wondered what was so special about October/April, leading Kevin to mysteriously pronounce[8] that he suspected he knew the answer. Disappointingly, rather than admitting to a counter-KDE conspiracy JesseKeating said[9] that October allowed some slippage without entering holiday time, while April was ideal for attention and resources. In a further demonstration of how carefully the conspirators had synchronized their stories, JeremyKatz gave nearly exactly the same answer[10] .

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02127.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02128.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02124.html

The Google Summer of Code deadline was raised[11] by MatthiasClasen as a possible reason to perhaps slip the draft schedule a bit. KevinKofler felt relieved[12] that GNOME wasn't being held to the same standards but argued that it was further reason to change the date. DavidNielsen reported[13] hearing that KDE was also going to target a six-month cycle and that the rough schedule could be maintained if Fedora were to attempt to synchronize with KDE. There was significant agreement with this, but ThorstenLeemhuis suggested[14] that it would be best to see if KDE4.0 actually manages to ship on time, and then to synchronize with KDE.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00059.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00069.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00156.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00200.html

What Should X-Chat Be Called In The Menu?

A debate over what the IRC client "X-Chat" should be named in menus raged briefly. X-Chat has been covered before[1] , as a possible example of how the community could help with packages post-merge. The discussion apparently spilled over from @fedora-extras with a post[2] from KevinKofler objecting to the manner in which some packages apparently do not follow the FESCo-approved guidelines about what a ".desktop" file should contain. The original post which Kevin was responding to is apparently not on @fedora-devel.

[1] http://fedoraproject.org/wiki/FWN/Issue88#head-93d08605503d8a9cb111d3d634105b9f7fc69915

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02138.html

MatthiasClasen thought that "X-Chat" was much less meaningful than "IRC", but Kevin and JoshBoyer[3] felt that even regular users coming from a Windows background would understand intuitively what was meant. Kevin also wondered why GNOME didn't support GenericNames in .desktop yet, which Matthias answered[4] by saying no one had got around to it yet. StuardChildern responded[5] by agreeing that the KDE solution of "X-Chat IRC" was the best. Even better, Stuart analyzed the problem as being solvable by adding a gconf dependency to libgnome-menu and volunteered to do this work himself.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02163.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02153.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00000.html

Matthias thought that the desktop team was getting slammed[6] both for being too like Windows and for not being similar enough and redirected his energies to productive use.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02164.html

OwenTaylor zoomed[7] the discussion back out to a bigger picture, noting that the use of GenericName was a holdover from a previous "Best of Breed" approach to Fedora. Owen posted links to screenshots illustrating the new approach which uses "Big Board" to display a lot more information about applications. Owen thought that it would be best for now to simply use the name "X-Chat IRC Client" as is done for Firefox, and ignore the GenericName. ToshioKuratomi agreed, but thought that the Big Board idea was similar to best-of-breed except that it depended on usage statistics instead of a best guess of popularity by the distribution.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00002.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00139.html

After JoshBoyer hastened to make it clear that he wasn't slamming anyone and Matthias clarified that "regular users" wouldn't be able to choose applications by name, NilsPhillipsen suggested[9] that the menuing/application-display utility could do some conditional display of names and genericnames.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00085.html

FreeTDS Inclusion

The maintainer of FreeTDS[1] (which allows interoperability with Microsoft SQL and Sybase) posted a request[2] for a reconsideration of a 2005 decision not to include FreeTDS in Fedora. HansdeGoede noted that there were already packages in the Livna repository, and asked TomCallaway if it would be necessary to consult Red Hat legal. Tom responded that he was satisfied that there was no patent problem, and while he disliked the only documentation of the standard being marked "confidential" the package could probably move to Fedora.

[1] http://www.freetds.org/

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02070.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02088.html

Simplified Kernel Spec File

ValentTurkovic asked for help[1] in getting suspend and resume to work properly on his laptop. NicolasMailhot noted the difficulty in getting a kernel to build from the vanilla source and patches due to the complication of the specfile. RahulSundaram delivered[2] the good news that this was being worked on and had been discussed on @fedora-kernel.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02044.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02148.html

RPM License Agreement Support

HikaruAmanu wanted[1] RPM to be patched so that it could present an EULA. ChrisBrown thought[2] that Fedora should do nothing to facilitate companies wishing to release non-Free software, and that the issue had been discussed previously.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01924.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01947.html

JesseKeating stated[3] that RPM installation had to be non-interactive. Several suggested that if this had to be done it should be post-install. JefSpaleta referenced[4] the old Macromedia flash-plugin as an example.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01934.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02013.html

Don't Put New Packages Through Updates-testing

A thread was moved[1] out of @maintainers by HansdeGoede for wider consumption. Hans was concerned that the new policy of making new packages go through updates-testing added an unnecessary extra step and delayed getting the packages into the hands of users. JesseKeating responded[2] that this wasn't a sudden change, that it had always been the idea to have new packages enter the updates-testing repository, and that the only new thing was using "bodhi" for them. Jesse also asked for actual statistics on how many people used the updates-testing repository and pointed out that the important thing was maintaing a stable release for users and that the QA process for rawhide was not the same.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00053.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00062.html

RalfCorsepius and HansdeGoede felt that it was unlikely that the testers using updates-testing would be able to appreciate the issues involved in many of the huge and technically complex packages that sometimes also require very specialist architectures. WillWoods responded with[3] an interesting link to his thoughts on how bodhi presented a balance between the (old) Fedora Core and Red Hat QA processes and emphasized that what QA testers did was to make sure that a baseline of verifying that there were no missed dependencies and that applications appeared to run without segfaulting. Further discussion suggested[4] that Hans already went above and beyond this sort of QA and that he would probably thus not experience the delays he feared. Hans also suggested some useful QA tests that should be added to the guidelines.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00077.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00131.html

Summing up[5] JefSpaleta suggested that "bodhi" exposed the updates process and opened up the possibilty for the time spent in updates-testing to be used in developing scripted QA tailored to each package in order to ease the maintenance burden slightly (using "beaker"[6] ).

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00142.html

[6] http://fedoraproject.org/wiki/QA/Beaker

JoshBoyer estimated[7] that the amount of time packages would spend in updates-testing was a week. In response to Hans' question as to what factors besides freedom were important to Fedora, Josh suggested that end-user stability was important.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00111.html

Hans expressed[8] a general feeling that there were too many rules and procedures instead of trust, prompting agreement[9] from PatriceDumas that the merge had seen a lot of control move away from maintainers. RalfCorsepius agreed[10] and suggested that functionality testing was upstream's job and that all a packager should be responsible for was whether the package was suitable for public use. MichaelSchwendt also felt that things were becoming a bit rule-bound, but thought[11] that testing against segfaulting was essential.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00212.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00214.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00222.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00224.html

RahulSundaram and Michael struggled to come to some agreement over what it would mean for a reviewer to test base functionality. A concern over the possible discouragement of reviewers was capped with Michael pointing out[12] the difficulties that even large upstream teams had in testing functionality and the closing of quick fixes by what he termed a new bureaucracy. Rahul admitted that the bar had been raised for reviewers and worried that users would react negatively to broken packages. Michael thought[13] that the new updates system was lacking in specific promised QA resources because FESCo had let the ball drop on these issues. ThorstenLeemhuis was strongly in agreement[14] , feeling that the transition to Koji had not been accompanied by the necessary agreements about how it would be used, resulting in loss of community control. NicolasMailhot disagreed[15] , and was suspicious of the frequent invocation of "community" in defence of large packagers to do what they wanted. Nicolas also noted that the transition had gone very smoothly. In response PatriceDumas drew[16] a distinction between packaging guidelines (which were under community control) and process and workflow (which were not).

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00230.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00232.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00259.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00285.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00287.html

A thoughtful post[17] from ToshioKuratomi responded to Thorsten's assertions about loss of community control by suggesting that what was happening was delegation of some jobs to teams (such as ReleaseEngineering and Infrastructure) and the absorption of the old core-packagers into the community.

[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00299.html

JesseKeating made sure[18] that it was clear that not every update had to go through updates-testing, and seemed to answer Hans' query about how to expose users easily to the availability of new updates. Discussion[19] about the mechanism seemed to end in a workable resolution.

[18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00087.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00134.html

Fedora Image As A GRUB Entry

Picking up on a report from ChristopherAillon about how he upgraded, JefSpaleta suggested[1] that it would be nice to provide an F7 package that created a GRUB bootmenu entry and an installer for F8. This would allow users without a DVD writer to do a network upgrade via the installer instead of a yum upgrade.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00109.html

WillWoods was among the many keen on the idea and suggested[2] the likely things such an installer would do. ColinWalters and Will were especially interested[3] in the possibility this opened up for regression testing of rawhide on a regular basis. SethVidal suggested caution[4] as many of the more fundamental changes (e.g. transition ext3->ext4) would not be easy to do on a live system. AlexanderBostrom wondered[5] if that specific transition could be handled by having everything downloaded and then using a pivot root similar to the manner in which anaconda does things.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00112.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00119.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00135.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00208.html

SindrePedersenBjordal reminded[6] the list that he had already posted about a package he had created that did exactly what was proposed.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html

https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00109.html

see also

https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00016.html

Maintainers

In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora

https://www.redhat.com/mailman/listinfo/fedora-maintainers

Contributing Writer: MichaelLarabel

EPEL Report Week 20

The results of the weekly EPEL meeting were published to the fedora-maintainers-list[1] . In this meeting, MikeMcGrath discussed the standing proposal to provide RHEL subscriptions to EPEL packagers, six new contributors were introduced bringing the total number of EPEL contributors to eighty, and now in total for EPEL 5 there are over 470 binary packages (EPEL 4 binary package count is currently at 358).

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01000.html

Bodhi and Fedora 7

In time for the release of Fedora 7, BillNottingham announced that Bodhi is now available[1] . For those out of the loop, Bodhi is a modular Turbo Gears system for issuing updates. AxelThimm had also requested a how to for bohdi[2] .

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01025.html

[2] https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00030.html

Documentation

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: JonathanRoberts

Fedora Documentation Steering Committee Meeting

The IRC log[1] and the summary[2] of the FDSCo meeting, from 27 May were posted to the docs-list.

[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00163.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00165.html

Meeting Location

KarstenWade proposed that the FDSCo move their meetings to the #fedora-meeting channel, as he believes more people are lurking there from across the whole project, and might encourage them to get involved with the documentation project meetings[1] . It was well received but decided that the current meeting time on a Sunday was too distracted by outside life, so the meeting time has been moved to 1600UTC on Tuesdays[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00177.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00182.html

ISO and Web-Only Release Notes

DimitrisGlezos writes[1] to the docs-list to remind people that the release notes[2] are published in two locations for the two different types. The release notes included in the ISO (that is, in F7 itself)[3] , and the updated, current ones (also called Web-only because they are not included in the release)[4] .

All translated docs that were included in the release should exist in[3] and be linked from[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00184.html

[2] http://docs.fedoraproject.org/release-notes/f7/

[3] http://docs.fedoraproject.org/release-notes/f7/iso/

[4] http://docs.fedoraproject.org/release-notes/f7/<lang>/

Documentation for Revisor and Other Spin-Making Tools

With the release of Fedora 7 there is one significant new feature that needs proper documentation: custom spins[1] . Anybody wanting to help contribute documentation for Revisor, Pungi, or Live CD Tools should post to the fedora-docs-list[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00001.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00007.html

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Infrastructure Server Organization

MikeMcGrath and others had a discussion this week about Apache tweaks[1] and general network setup[2] .

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00198.html

[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00207.html

Bodhi

LukeMacken and others got Bodhi[1] up and running this week.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00267.html

New Projects

Following the Fedora 7 release, two of the new initiatives requiring Infrastructure resources were posted about this week.

DimitrisGlezos is kicking off[1] his Summer of Code effort[2] , which involves a common WebUI for Fedora translators that can be used for contributing up stream as well.

Another project waiting for Fedora 7 is the click-through CLA for the Wiki, which replaces the need to have a GPG-signed CLA before contributing to the Wiki. KarstenWade is requesting[3] an Infrastructure resource to assist with this effort.

[1] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00041.html

[2] http://fedoraproject.org/wiki/SummerOfCode/2007

[3] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00036.html

Artwork

In this section, we cover Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: JonathanRoberts

Fedora 7 Disc Labels

LuyaTshimbalanga posted the final artwork for the Fedora 7 CD labels[1] , with the color stripped out from the original EPS in 8 monochrome colors. The artwork is available as both an SVG and an EPS. Shortly afterward, an updated SVG was also posted[2] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00053.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00054.html

Editor's Note: Official Fedora 7 Labels are available at http://fedoraproject.org/wiki/Artwork/CDArt

Default Desktop Theme?

A message was posted to the art-list suggesting that the Fedora theme needs to be "polished"[1] . The central argument was that although the artwork sees a lot of attention every release, the theme - including panels and window borders - looks the same each release[2] . Linux Mint and Ubuntu Studio were both used as examples of what could be achieved, but it appears that for any new theme to receive popular backing, it can't resemble Vista[3] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00060.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00064.html

[3] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00067.html

Fedoraproject.org Banners

Nown that the new home page is in place, the idea has been proposed to include banners advertising special events and drawing focus to community created spins of Fedora. Anybody interested in creating banners for the home page should post to the fedora-art-list[1] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00069.html

Brazilian Banners

JaymeAyres contributed some banners he created to the list[1] . They are animated GIFs using the Flying High theme and were very well received.

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00082.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00000.html

Advisories and Updates

In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce.

Contributing Writer: ThomasChung

Fedora 7 Advisories and Updates

Fedora Core 6 Advisories and Updates

Fedora Core 5 Advisories and Updates

Events and Meetings

In this section, we cover event reports and meeting summaries from various projects.

Contributing Writer: ThomasChung

Event Report: IV ESLAM - Amazon, Brazil

Fedora Ambassadors Meeting Minutes 2007-MM-DD

  • No report in this week

Fedora Documentation Steering Committee 2007-MM-DD

  • No report in this week

Fedora Engineering Steering Committee Meeting 2007-05-31

Fedora Packaging Committee Meeting 2007-05-29

Fedora Release Engineering Meeting 2007-MM-DD

  • No report in this week

Feedback

This document is maintained by the Fedora News Team[1] . Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help.

[1] http://fedoraproject.org/wiki/NewsProject

[2] http://fedoraproject.org/wiki/NewsProject/Join

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue90&oldid=6143"