From Fedora Project Wiki

< FWN‎ | Beats

m (fix some wikinames)
(first pass 135 fedora-devel)
Line 1: Line 1:
{{Anchor|Developments}}
{{Anchor|Developments}}


=== New RPM Sparks Exploded Source Debate ===
=== Kerneloops for SELinux ===


The announcement[1] of a sparkling new alpha-version of RPM by [[PanuMatilainen]] was greeted with congratulations and applause and later some passionate argument. It has been approximately one year since Panu solicited (see FWN#98 "Panu Opens Pandora's Box"[2] and FWN#99 "RPM Roadmap (Cont.)"[3]) suggestions from those not intimately involved in RPM development as to which problems should be fixed. This initiative was taken after deciding to move RPM-4.4 to bugfix maintenance due to artistic differences with the current RPM coder (who then led a very public fork named RPM5[4]). Panu's new RPM-4.6.0 implements many of those suggestions as detailed[5] in the release notes and many of those involved in the initial roadmap process (such as [[RalfCorsepius]] who cleaned[6] up the ''autotool'' stuff also helped to implement the desired changes. By Panu's estimate over 2300 commits were made[7] to the source since the initiative to get RPM development back on schedule began, and although the wiki provides[8] essential details of what has been implemented there is still a good deal of information lacking.
The last furore[1] over SELinux contained a positive contribution from StewartAdam, who proposed[2] to improve the interaction between users and SELinux by means of a "kerneloops-like plugin [which] would allow for statistics on where denials occur most and that way the policy could be modified accordingly." DanWalsh commented[[3]] that JohnDennis had written the ''setroubleshoot'' tool[4] to include the ability to send messages to an upstream collector. Dan was worried that he would be chosen as "the upstream infrastructure to handle all the messages" but optimistic that "the XML data [could be] run through some tools to see if the AVC was fixed by a newer version of policy". RobinNorwood thought[5] this would be easily solved using TurboGears[6] and Stewart concurred[7].


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00477.html
[1] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth


[2]http://fedoraproject.org/wiki/FWN/Issue98#RPM.Roadmap.....Panu.Opens.Pandora.27s.Box
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01081.html


[3] http://fedoraproject.org/wiki/FWN/Issue99#RPM.Roadmap..28Cont..29
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01085.html


[4] http://rpm5.org/
[4] The ''setroubleshootd'' daemon listens for AVC denials and passes them through a series of plugins to analyze the audits and report what has been prevented. Suggestions are made on how to fix denials. On the client side ''sealert'' provides either a GUI or plain CLI interface which can connect to either the local machine or to a remote ''setroubleshootd''. The daemon can be configured to send email alerts. Making changes to system policy can be done in a variety of ways. The aforementioned sealert often suggests a simple CLI sequence to run. The older CLI ''audit2allow'' and ''audit2why'' tools respectively generate fixes based on the audit logs and explain them. ''semanage'' allows changes to be made on the fly to SELinux policies and ''system-config-selinux'' also allows boolean selection among pre-written policy options and the easy changes of ports or filecontexts.


[5] http://wiki.rpm.org/Releases/4.5.90
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01087.html


[6] http://www.mail-archive.com/rpm-maint@lists.rpm.org/msg00386.html
[6] A web framework written in Python which is widely used in Fedora Project infrastructure.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00538.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01093.html


[8] http://wiki.rpm.org/Releases/4.5.90
A substantial chunk of the rest of the discussion hovered around the topic of whether some button(s) should be added to make it easier for the user to ignore the problem. Similar ideas had been floated (see AlanCox's and JamesMorris's comments in FWN#133, ref 7&8 [8]) earlier and AhmedKamal made[9] a good summary of them. He suggested that an AVC denial would present two buttons: "AutoFix" would try to enact the recommended fix stored in the database; and an "Exempt" button which would allow the offending application to run unrestricted. The latter especially was intended to prevent users from just switching off SELinux entirely. ArthurPemberton and StewartAdam thought[10] that this was exactly the wrong approach, with Arthur being reminded of MS Vista users automatically clicking "allow" and Stewart commenting "The idea of this is to get users to report what's going wrong and get it fixed in the policy instead of exempt/disable which defeats the purpose and trains the user to hit "Exempt" without reading anything." Ahmed took the point and made the modification that the "Exempt" button would only work once-per-launch. He argued this would allow the user to get work done but still preserve the incentive to get the problem fixed. DaveAirlie appeared[11] somewhat upset at the idea, arguing that this was "NO NO NO ... DOING IT WRONG."! Taking a cue from the implicit messages of the iMac vs. Windows television advertisements and the successful model of kerneloops he insisted that users should "[never be involved] in the mess other than asking for opt-in [...] The user is not going to have a freaking clue wtf exempting means." Instead he suggested that pinging a remote server to ask for an updated policy would be superior.


The announcement contained suggestions for users (of Rawhide where the alpha is available) about how to trouble-proof themselves and a more extensive list of notes for packagers. Of note are the changes to the macros to eliminate the old buildroot directory defaults and ignore[9] the BuildRoot in an rpm's spec file, and the addition of support for LZMA[10] compression. Another cool new feature is the addition of a macro to allow iteration over all patches, something which was welcomed[11] by [[JarodWilson]], who noted that RHEL5 needed 1800 lines in the kernel specfile solely to mention each patch.
[8] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00531.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01089.html


[10] http://en.wikipedia.org/wiki/LZMA
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01092.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00502.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01101.html


It seems that a massive amount of work has gone into API changes and internal cleanup of the code in order to set up a framework for the addition of new features in the future.
Replying specifically to the idea of an "Exempt" DanWalsh noted[12] that there were such policies (called "permissive domains") now available in Rawhide. He went on to restate the problem that "Teaching people to press a button to tell SELinux to disable protection [because of AVCs that don't really block anything will get them to disable it when a real attack comes along." Instead the SELinux developers are concentrating on eliminating many of the false AVCs and one of the recent changes towards this end is the addition of a new access permission "open". JamesMorris added[13] that he had written about this work, as implemented by EricParis, in his livejournal: "Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate "open" check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output."


[[ThorstenLeemhuis]] expressed[12] happiness with Panu's contribution but wondered whether the FESCo Feature process[13] had been shown to be unnecessarily bureaucratic by the manner in which this change had occurred. [[JoshBoyer]] and [[JeffSpaleta]] drew[14] a slightly different lesson and suggested that it ought to be made easier for a developer to determine whether their package upgrade should be filed as a feature. Panu also agreed[15] that Thorsten's points were fair but excused himself on the grounds of concentrating on upstream RPM development and not being sure what the demarcation between feature and non-feature was.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01091.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00549.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01170.html


[13] https://fedoraproject.org/wiki/Features/Policy
DanWalsh, in response to questions from ArthurPemberton,listed[14] the private information contained in an AVC denial as "Hostname, filename, potentially username, rpm information. What apps they are running."


[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00562.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01132.html


[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00565.html
Dan was also concerned that any new upstream reporting only occurred when ''setroubleshoot'' had been unable to find a suggested fix in its database. He reported that many bugzilla entries filed against him appeared to indicate that users did not even attempt the actions indicated as potential fixes by ''setroubleshoot''. ArjanvandeVen suggested[15] that ''setroubleshoot'' should just make those changes. DavidTimms wondered whether suggesting such "let this happen anyway" actions to users should be considered risky and not dissimilar to Ahmed's "Exempt" and "FixMe" buttons. He also listed several means by which he considered SELinux could be improved. DanWalsh replied[16] that many of these desired capabilities were already present in SELinux but appeared to ignore the behavioral similarities argued by David.


[[PaulFrields]] suggested[16] that it might be useful to think of the "Fedora feature process as leveraging what Fedora can provide for an upstream community. Two things that come to mind immediately are QA/testing and widespread publicizing of the feature." [[JohnPoelstra]] also drew attention[17] to the synergistic advantages of the Features process resulting from its public communication of what is being worked on currently. [[CallumLerwick]], responding to Thorsten, gave his understanding of the Features process as "a conduit for the Engineering side of Fedora to collaborate with the Marketing side of Fedora, to allow the Marketing people to build up pre-release hype for new features without having to second-guess us notoriously busy, and quiet, engineering types. It allows the Marketing people to keep tabs on engineering activities and have reasonable certainty as to the status of the feature, specifically whether or not it is going to be finished in time for the final release." He emphasized the voluntary participation of developers and software engineers in the process and the benefit resulting from having marketing clued-in to interesting changes. [[JesseKeating]] responded[18] that the process was "way more than just marketing fluff. Features have very real schedule impact, just consider this time around, RPM with a bunch of new features, and a new gcc coming at some point soon. Usually we want to rebuild for both of those. Without some high level coordination, how do we schedule so that we rebuild once for all of the right reasons instead of multiple times individually?" The marketing advantages of the Feature process were confirmed[19] by [[PaulFrields]]. [[MatthiasClasen]] made[20] some concrete suggestions on how to improve the Feature process. They included the addition of definitions or explanations for each section and the perception that the review of his feature pages felt a bit like getting homework graded.
In response to further questions from ArthurPemberton it seemed[17] that the preferred mode for such a tool would be to suggest installation of any available updated policies either via PackageKit offering to install them or a "yum update".
[16] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00580.html


[17] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00581.html  
[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01193.html


[18] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00626.html  
[16] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01138.html


[19] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00582.html  
[17] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01151.html


[20] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00645.html
=== Process Wakeups and Energy Efficiency ===


The point about co-ordination of activities was highlighted when [[DougLedford]] confessed[21] that his first reaction had been "Oh hell...what a colossal waste of time" when he realized that he had spent a week studying what was now obsolete RPM source code. Panu's friendly response that Doug "could've just asked" drew out the central problem: "Yeah, I know, I just didn't know a big update like this was in the works." Doug's interest lay[22] in extending ''rpmdb'' to add fields to allow interaction with SCMs[23] mostly "to be able to support exploded source repos and usage of exploded source repos as canonical source versions of binary packages." Panu answered[24] that these sorts of changes were probably post-Fedora 10 and that he too was keen to integrate with SCM tools. He pleaded for some more patience to settle this clean, new codebase down before implementing such changes: "I know. People have been waiting SO long for various things to happen in RPM that everybody's out of patience and wants their stuff in NOW. Please try to be patient a little bit longer: once this release stabilizes, RPM can move to a "normal" development-release cycle where folks will not have to wait 5+ years to get their changes in :)" [[SethVidal]] and [[ToshioKuratomi]] were impatient with Doug's impatience[25,26] with the latter noting that Fedora Policy "to allow using source control repos interchangeably with tarballs would [not] be approved in time for F10 either."
UlrichDrepper posted[1] a systemtap script which revealed a list of applications which cause wakeups due to timeouts. He noted that "Programs should be woken based on events. They shouldn't poll data (which is what usually happens after a timeout)" and requested that package maintainers for the programs in the list try to help solve the issue. The Flash ''npviewer'' was clearly the worst offender. The creator of the ''PowerTOP'' program, ArjanvandeVen wondered[2] why this work could not have been done using PowerTOP.
[21] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00683.html


[22] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00694.html  
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00921.html


[23] http://en.wikipedia.org/wiki/Software.conofiguration.management
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00931.html


[24] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00696.html
MatthewGarrett thought[3] that polling was inevitable for many applications but that the Glib timer function {{g_timeout_add_seconds}}[4], which allows a function to be called at repeated intervals until it is automatically destroyed, could be used to do this at low frequency. It turned out[5] that this was exactly the approach which ArjanvandeVen had taken. HaraldHoyer thought that this was non-ideal as it did not sync globally and while Matthew agreed that kernel support would be needed DavidWoodhouse speculated[6] that tackling the problem per-thread instead of per-event might be possible.


[25] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00702.html  
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00938.html


[26] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00699.html
[4] http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-timeoutadd-seconds


Later Panu requested[27] that packagers "refrain from using the new spec features in Fedora to minimize the fuss in case disaster strikes and we need to go back to rpm 4.4.x. The new rpm is on probation for a while ;) Please do test and use the new things as much as possible in private, just not yet in Fedora CVS.  A further notification will be sent when the probation is over."
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00962.html


[27] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00703.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00968.html


Doug expended a good deal of effort both trying to get an answer as to whether there was any point in him trying to go ahead and add some of the basic features which he thought were necessary, and also explaining why the ability to interact directly with a distributed SCM/VCS instead of through the middle-man of a tarball was a good idea. Among the advantages Doug described were "since you built the binary packages from this exploded source repo, then in order to give people the exact sources you built from, you need to make the repo available for clone/checkout by people. You need never once build an srpm or tarball from this repo if you don't want to [...] the first advantage to this type of setup is that every SCM worth a pile of dog poo will store the different versions of software in some form of change related format that keeps you from duplicating the same things over and over again like tarball after tarball does. You generally take a hit in size versus a single tarball, but end up saving quite a lot in the long run [...] you get to work on the code in native format, try things out, run build tests, and all the while the pain of repetitive rpm source processing is reduced[...]" Doug went on to explain that in the case where the upstream also uses a distributed SCM then things become even easier. He attached his notes (in ''tomboy'' format) with yet more detail.
NilsPhilippsen added[7] that it should be possible to use IMAP IDLE to fix mail clients and servers that polled too frequently.


Doug was obviously brimming with ideas about how this would make Fedora development easier and reacted[28] with a certain amount of frustration to Panu's and Seth's assumption that he was asking them to do something which they could not get around to until Fedora 11. Doug also pointed[29] out that the problem of forcing the creators of spins to distribute their own sources was also possibly solved by using distributed SCMs and that he had discussed this with [[JesseKeating]] at the recent FUDCon. His perception was that the Fedora Project was actively blocking Red Hat's needs. [[JesseKeating]] later returned[30] to the problem of compliance with the distribution requirements of the GPL: "I either have to offer you a CD/DVD of corresponding sources in <insert vague nonlegal terms here> format, or provide you a written offer to provide the above that is good for the next 3 years, or pass along such written offer that I myself may have gotten. Nobody has confirmed nor denied what that <vague nonlegal terms here> means, nor how long the 3year clock ticks on those formats, and whether or not directions on how to get the source from our public source repo is OK."
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01032.html


[28] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00729.html
RichardHughes quickly jumped[8] in to report a fix for his PackageKit problem but was less sanguine that GNOME Power Manager could be fixed quite so easily, although there was an expectation that Xorg would fix things by sending out a notification of changed DPMS state.


[29] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00776.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00948.html


[30] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00793.html
DanielBerrange provided[9] some evidence that the apparent problem with ''libvirtd'' was actually due to DBus sending unrequested signals every six seconds. When DanWilliams took a look[10] at NetworkManager's contributions and explained some problems were due to the ''ipw2200'' drivers waking up all WEXT listeners every four seconds and others were due to the presence of bogus rfkill switch events in HAL Daniel connected[11] the dots and said "Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux to be run every 6 seconds, which in turns causes any app connected to DBus system bus to be send a signal every 6 seconds and thus causes all the hits against libvirtd - and a fair number of other apps in that list too." DanWilliams responded that it was possible, but that it might be worth checking to see if D-Bus signal filtering was being done properly. The forthcoming 2.6.27 kernel was also said to contain the appropriate patches for rfkill which would help solve the problem.


This has been an inadequate summary of a complex topic. If you are interested in it you are well advised to read the thread especially Doug's posts and the responses to them. They start here[31].
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00973.html


[31] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00683.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00976.html


=== Fedora EDU Spin Preview Temporarily Pulled ===
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00978.html


A spin targeted at educational environments, "Fedora EDU"[1], was announced [2] as available in preview by [[SebastianDzillias]]. He explained that its focus was on mathematical applications with a KDE-4.1 desktop environment and that it was currently x86 only.
Problems with ''PulseAudio'' were guessed by LennartPoettering to be due to the aforementioned Flash player ''npviewer'' opening audio streams and never closing them which in turn caused PulseAudio to keep the device open. Again there was a promise of future improvement as Lennart mentioned that the version of PulseAudio in rawhide should not generate any wakeups when completely idle.


[1] http://fedoraproject.org/wiki/SIGs/Education/Roadmap
It would seem that Ulrich's initiative may yield some useful improvements.


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00628.html
=== Nodoka Notification Theme a Fedora 10 Feature ===


[[JesseKeating]] was quick to point out[3] that the use of the KDE-4.1 preview provided by the "kde-redhat" repositories meant that the spin could not use the "Fedora" trademarks. [[JoshBoyer]] amplified[4] on this with the information that "you need to get Board/Spin SIG/Rel Eng approval to call a spin a Fedora spin" and that there was no need to use the kde-redhat repositories as Rawhide already had the KDE preview packaged up. [[ChristopherAillon]] also noted the existence of the SpinSubmissionProcess and [[LukeMacken]] wondered [5] whether anyone wanted to help out in creating a "fedora-spins" mailing list to help unblocked that process.
MartinSourada asked[1] for help determining whether his plan to provide a beautiful new notification theme for Fedora 10 counted as a "Feature" (see FWN#135 "New RPM Sparks Exploded Source Debate refs 10-20 for recent discussion of the Feature process.) The notification daemons are responsible for popping up small, dismissable windows informing the user that certain events have occurred[2][3].


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00629.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00842.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00632.html
[2] http://freedesktop.org/wiki/Specifications/systemtray-spec


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00651.html
[3] http://developer.gnome.org/doc/guides/platform-overview/platformoverview.html#notification-area


Further discussion between [[RexDieter]] and [[JoshBoyer]] revealed[6] that the spin was also based on Fedora 9, which led Josh to suggest that new spins should dovetail into the release process and specifically that this one should be based off Fedora 10. Rex agreed that this had been the plan, but that this was simply a preview to obtain feedback. [[JeffSpaleta]] thought[7] that "Preview binaries are great, because it shows that these particular Spin developers are making their best effort to get this working and tested[.]" He asked for confirmation that there was no actual policy preventing such preview spins being built against the current (as opposed to rawhide) release and suggested that the main problems were "they pushed ahead and used non-fedora binaries in what they published [and] [w]e don't want anyone out in the wild to get the idea that this is a baked concept. The generic logos are there specifically so we can do preview spins like this." [[JoseMatos]] thought[8] that the question should be extended beyond spins to consider the general case of "non-official" repositories such as the TEXLive, Python-2.5 and other repositories. Although he was aware of the inherent possibility of diluting rawhide testing due to such repositories "I would have expected that by now we had some kind of mechanism to deal with such cases other than the non-official stance of every of those repositories." [[CharlesDostale]] thought[9] that an ultra-rawhide as hinted at by Jose would be interesting.
Martin stated that the public test release had been available for three months and no issues had been reported. He explained how to obtain the new theme from Koji and how to make it available to the system. After encouragement from RahulSundaram that such a visible change should be considered a feature Martin created a feature[4] page in the wiki. Further feedback from Rahul resulted[5] in the addition of screenshots and a Test Plan section.


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00637.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00901.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00644.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00908.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00650.html
WillWoods wrote[6] a concise and informative overview of what was expected from Test Plans.


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00690.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00912.html


[[JeroenvanMeeuwen]] agreed[10] with Jeff that there was no current hard policy against working off the current release and decided to "propose to the spin sig to have the spin-kickstarts master branch use generic-logos (master branch is for development so basically anyone can do anything there)." [[RexDieter]] took responsibility and announced on his blog[11] that the spin was pulled until the aforementioned problems had been resolved.
=== Mono Beta ===


[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00653.html
PaulJohnson announced[1] that a new beta of ''mono'' was about to hit the servers and would probably break a number of things. Also of note was the change of license to MIT for Mono-2.0.


[11] http://rdieter.livejournal.com/2008/07/10/
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01123.html


Later Jeroen posted[12] an explanation and request for how those wishing to produce official Fedora spins should proceed. An exchange[13] between [[JesseKeating]] and [[RahulSundaram]] focused on the question of whether FESCo should, as the designated body, be the one to decide whether the "desktop" and KDE variants were not spins. Jesse argued that because they were produced as part of the distribution they should be treated as "in essence the non-contrib part" and thus not to be treated as spins. Jesse argued strongly that it was "ill advised [for FESCo to have voted that spins are not features and] Releng and the Spins SIG want them to be features, and I'll use my powers in FESCo now and the board as well if necessary to push that agenda." He returned to the theme that Features were essential to the process of co-ordinating the production of a release. Rahul agreed[14] with the logic of Jesse's argument but disagreed with the over-riding of FESCo's decision "[..] if FESCo makes a decision, it should be the same group reversing it instead of any of us arbitrarily deciding otherwise. There is no point in FESCo making such decisions otherwise." [[JeffSpaleta]] also appeared[15] to believe that the decision-making process was slightly off-kilter.
DavidNielsen was excited and wondered if this would be pushed into Fedora 8 and Fedora 9 once any obvious breakage had been fixed. BillNottingham did not think 2 that "breaking the entire ABI and licensing of mono in released distros is a *good* thing. Especially Fedora 8." David expressed the advantages of pushing out one big update with a completely revamped stack to which WillWoods replied[3] that it made more sense to wait for Fedora 10's release in three months' time. David returned[4] to the idea that "having the same Mono throughout our releases is easier to maintain [and] pushing newer versions of the stack will enable us to support applications more widely across the stack." He suggested shipping a Fedora 9 preview release and drew a parallel to the situation with KDE-4.1 and their QT libraries. KevinKoffler disputed[5] the parallel as "Qt-4.4 and KDE-4.1 aren't breaking binary compatibility[.]"


[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00686.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01156.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00720.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01158.html


[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00724.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01160.html


[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00721.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01163.html
 
=== Fedora, Meet OLPC. OLPC, Meet Fedora ===
PaulJohnson explained[6] that until all the breakage had subsided only Rawhide would see the new beta "To me, rawhide is there for exactly this purpose - a testing ground to see how much is broken before pushing to stable." JeffSpaleta wondered 7 what the purpose of "updates-testing" was in that case.
 
[[GregDeK | Greg De Koenigsberg]] asked[1] Fedora packagers to help out the OLPC project by taking up the reins as far as package maintenance goes. He noted that contrary to some press reports the OLPC project has not died and quoted some surprising statistics: "OLPC has shipped over 300,000 units to kids around the world. They plan to ship at least another 50,000 more each month, and very likely more than that. It's entirely possible that by the end of 2008, there will be a million OLPC systems deployed worldwide. Of those systems, 100% of them currently run Fedora, and 0% of them currently run Windows despite the press clippings you may have read." Greg argued that this made OLPC Fedora's single largest customer and that the community was exceptionally well placed to help this continue. Some of the tasks were "simple issues that even novice packagers could handle." [[JeffSpaleta]] suggested that a "Sugar Desktop Spin" for standard PC hardware with a SIG to help organize around would improve efficiency.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00433.html
 
[[DebarshiRay]] wondered[2] "Can someone running vanilla Fedora (8/9/etc.) without any physical access to the XO hardware maintain/use OLPC packages?" and [[DennisGilmore]] answered[3] unequivocally "Yes, there is only a tiny handful of packages that are specific to the hardware/setup of the XO. the rest should always be applicable for use outside of the XO, sugar is in F-9 there is still some kinks in regards to the packaging that needs fixed. but if it doesnt work right on a normal fedora desktop its a bug and needs fixing." [[ChristopherAillon]] pointed out[4] that plenty of packagers maintain their packages for architectures, such as PPC, for which they do not have physical hardware and that XO was no different.
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00461.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00462.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00463.html


[[ColinWalters]] thought[5] that simple manual fixing of problems missed the opportunity to automate the process where appropriate.  [[DanielDrake]] raised[6] a related point, based on his experience of working on upgrading the OLPC from Fedora 7 to Fedora 9, which was that there appeared to be ever increasing bloat as a result of dependency chains. Due to the limited space on the XO Daniel requested help in slimming things down somehow. [[MatthiasClasen]] remembered[7] that when he had been involved with OLPC it had been necessary to do a lot of "dependency pruning." He advised that the best course of action was to "keep fighting this by filing bugs and pointing out package split candidates, since these deps have the tendency to grow back." [[RahulSundaram]] noted[8] that the need to produce LiveCDs helped combat the bloat tendency and [[RichardJones]] separately mentioned[9] ''oVirt''[10] in the same context.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01189.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00439.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01195.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00490.html
=== Policy On Non-Responsive Maintainers ===


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00503.html
The issue of non-responsive maintainers was aired[1] when PatriceDumas suggested a new policy designed to force maintainers to answer "easy fix" bugs or orphan packages. While Patrice worried that it might look rude he emphasized that the intent was to spread co-maintainership and obtain quicker bugfixes. While most contributors acknowledged the intent behind this they saw myriad problems.


[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00512.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/thread.html#00796


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00529.html
EricSandeen quickly raised[2] the problem of defining an "easy bug". AndrewBartlett thought[3] that this was potentially just "a stick to hit a stressed developer with - and surely developers under external stresses, who do not maintain Fedora packages as their day, job will be the ones most likely to have this stick waved at them. Their re-action may not be the one they or you want in the short and long term."


[10] http://ovirt.org/
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00745.html


After [[MatthiasClasen]] told Daniel that ''gvfs'' would possibly be split-up for Fedora 10, but that it was unlikely without a fork for Fedora 9, [[DennisGilmore]] added that he had been working on always tracking Rawhide for the olpc and that a Fedora 10-based build was possible. [[DanielBerrange]] spoke for the ''oVirt'' project when he expressed[11] a desire for tools to produce nightly reports on statistics such as the "disk footprint of the chain starting from package 'X', or list of dependencies from package 'X', or perhaps something that given a kickstart file can report the total size of the package set listed in the kickstart without actually going through the full livecd (or equiv) build process." SethVidal offered to take care of this and Daniel added[12] some further desiderata. Shortly afterwards Seth whipped-up an implementation to which [[JeremyKatz]] commented "The thing which becomes important to see is growth (or shrinkage) in packages as well as what new packages/removed packages there are. Which involves fiddly questions of growth thresholds and human analysis of the output." [[DavidTimms]] was excited[13] by the output, including what it appeared to reveal about the minimal set of install packages. Seth ended up modifying the output to a simple format which allowed[14] the use of standard UNIX text-processing commands to do fun things with the output.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00845.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00519.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00525.html
The issue of whether or not a fix had to, or could be, determined as correct was also seen[4] as a problem by BillNottingham and JesseKeating.


[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00649.html
A very detailed and thoughtful response from MichaelSchwendt to MatejCepl outlined[5] the problem of increasing the volume of bureaucracy and email dealt with by maintainers. It's worth reading to understand the stresses mentioned by other posters including AdamJackson and NigelJones who described[6] typical volumes of email which they faced. Adam added that anyone was welcome to help him fix bugs. Michael suggested instead that there be "a policy for package maintainers to respond to specially marked tickets from fellow fedora contributors in a timely manner. And if that results in tickets which are still not answered, timeout periods can be applied and give contributors the opportunity to prepare a test update (and only a test update!)." JesseKeating liked[7] the idea and added that SIG meetings could help to triage bugs.


[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00685.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00894.html


=== Getting Rid of pam_console for Fedora 10 ? ===
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00937.html


Currently Fedora sports both ''pam.console'' and HAL-based ACL support and [[BillNottingham]] posted[1] that it was "time to cut the cord and remove pam.console, so we only have one way of setting device permissions to worry about." He attached a list of affected packages.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00856.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00555.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00939.html


[[ChrisAdams]] wondered[2] how he would implement HAL-based ACLs for his serial ports to access other consoles. Following Bill's request for an ''lshal'' output and a pointer to an example HAL policy Chris's own stab at producing the policy seemed to pass muster. He added "I have another system where I have multiple USB-to-RS232 adapters; one is used for outbound terminal sessions (console user gets access) and one for a modem (no console access). I differentiate between the two with a udev rule that adds a symlink (e.g. "term" and "modem") and then set the permissions with a pam.console match on the symlink. Is it possible to match something set from udev like that (so I don't have two places to keep track of hardware serial numbers and such for matching)?" Bill's reply suggested examining ''/usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi'' and ''/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi'' in order to see respectively how varying information in HAL is handled and then ACL management is applied. This led a happy [[JeffSpaleta]] to exclaim[3] "that was the first explanation of how to do this sort of thing on how to generate new hardware access control rules that I've actually followed."
HansdeGoede thought[8] that it would be better to address the problem of how to allow others to help make easy fixes. He argued that it ought to be possible to use ACLs to allow "easy fixes" to be committed by anyone with CVS extras permissions if a developer has allowed it. Patrice replied[9] that the cases which he was concerned about were not owned by maintainers who would allow such changes.


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00567.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00757.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00570.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00764.html


[[DavidZeuthen]] corrected[4] Bill's description of the surgery to "the plan is actually to move this to ConsoleKit (HAL is going away and all that etc. etc.) but that's most likely F11 material. So suggest to hold off this feature for now." This might reassure [[DmitryButskoy]] who commented[5] that pam_console's "auth" features were useful.
Another voice against too much bureaucracy was that of RichardHughes who queried[10] "Surely the maintainer in question knows the package well enough to decide whether to merge patches? For instance, I might push a patch upstream and hold off applying it to fedora as it's trivial and will get updated at the next version bump of my package in a few weeks" to which KevinPage replied that there were examples where the timeframe was closer to numerous months. JeffSpaleta pushed[11] the idea of putting "packages under the purview of maintainer teams who are comfortable working with each other and care about the packages in question regardless of who the primary owner of a package is. SIGs are the obvious construct here[.]"


[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00621.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01004.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00608.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01008.html


=== New PackageKit and GNOME-packagekit in Fedora 9 ===
Refinement of the policy was carried out between RahulSundaram and ToshioKuratomi. Toshio wanted[12] to make it possible for a co-maintainer to be added in egregious cases to help ease the burden on the original maintainer.


[[RichardHughes]] drew attention[1] to the availability of API-breaking update of ''PackageKit'' and ''gnome-packagekit'' in the Fedora 9 "updates-testing" repository. He requested testing and bug reporting via email.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00918.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00304.html
The emphasis on orphaning packages aggressively over a short time-period was questioned[13] by DanielBerrange. He suggested that adding co-maintainers would be a better strategy. RichardJones added[14] the disturbing spectre of "Wikipedia-style deletionism" occurring.


Richard noted that speed-wise there would be a major improvement coming much later based upon his work on profiling ''yum'' and working around "slow paths in the API [...] For instance, the group list used to take 14 seconds on my machine, and now completes in less than a tenth of a second using master." [[SethVidal]] cautioned[2] against Richard's approach of accessing the SQLite databases directly instead of going through YUM's layers and suggested that instead "I've implemented a searchNames() method to pkgSack in yum which will let you search very quickly for multiple package names."
[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00946.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00305.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00982.html


Most of the other responses reported no significant issues after several days of testing, except that [[MartinSourada]] found[3] some non-intuitive behavior when installing local rpms and a potential security hole.
Some balance was added by a post made[15] by KevinPage which conveyed the perspective of frustrated bugzilla posters who find their easy fixes ignored. Kevin explained his experience with trying to get his patches applied and wondered whether it was a consequence of the new emphasis on pushing bugfixes upstream. He finished with "One conclusion from this thread is that it's accepted that some maintainers don't follow bugzilla. Not condoned, but accepted as a reality. That's clearly incompatible with asking users to report their problems in bugzilla."


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00309.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01005.html

Revision as of 02:36, 20 July 2008

Kerneloops for SELinux

The last furore[1] over SELinux contained a positive contribution from StewartAdam, who proposed[2] to improve the interaction between users and SELinux by means of a "kerneloops-like plugin [which] would allow for statistics on where denials occur most and that way the policy could be modified accordingly." DanWalsh commented3 that JohnDennis had written the setroubleshoot tool[4] to include the ability to send messages to an upstream collector. Dan was worried that he would be chosen as "the upstream infrastructure to handle all the messages" but optimistic that "the XML data [could be] run through some tools to see if the AVC was fixed by a newer version of policy". RobinNorwood thought[5] this would be easily solved using TurboGears[6] and Stewart concurred[7].

[1] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01081.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01085.html

[4] The setroubleshootd daemon listens for AVC denials and passes them through a series of plugins to analyze the audits and report what has been prevented. Suggestions are made on how to fix denials. On the client side sealert provides either a GUI or plain CLI interface which can connect to either the local machine or to a remote setroubleshootd. The daemon can be configured to send email alerts. Making changes to system policy can be done in a variety of ways. The aforementioned sealert often suggests a simple CLI sequence to run. The older CLI audit2allow and audit2why tools respectively generate fixes based on the audit logs and explain them. semanage allows changes to be made on the fly to SELinux policies and system-config-selinux also allows boolean selection among pre-written policy options and the easy changes of ports or filecontexts.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01087.html

[6] A web framework written in Python which is widely used in Fedora Project infrastructure.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01093.html

A substantial chunk of the rest of the discussion hovered around the topic of whether some button(s) should be added to make it easier for the user to ignore the problem. Similar ideas had been floated (see AlanCox's and JamesMorris's comments in FWN#133, ref 7&8 [8]) earlier and AhmedKamal made[9] a good summary of them. He suggested that an AVC denial would present two buttons: "AutoFix" would try to enact the recommended fix stored in the database; and an "Exempt" button which would allow the offending application to run unrestricted. The latter especially was intended to prevent users from just switching off SELinux entirely. ArthurPemberton and StewartAdam thought[10] that this was exactly the wrong approach, with Arthur being reminded of MS Vista users automatically clicking "allow" and Stewart commenting "The idea of this is to get users to report what's going wrong and get it fixed in the policy instead of exempt/disable which defeats the purpose and trains the user to hit "Exempt" without reading anything." Ahmed took the point and made the modification that the "Exempt" button would only work once-per-launch. He argued this would allow the user to get work done but still preserve the incentive to get the problem fixed. DaveAirlie appeared[11] somewhat upset at the idea, arguing that this was "NO NO NO ... DOING IT WRONG."! Taking a cue from the implicit messages of the iMac vs. Windows television advertisements and the successful model of kerneloops he insisted that users should "[never be involved] in the mess other than asking for opt-in [...] The user is not going to have a freaking clue wtf exempting means." Instead he suggested that pinging a remote server to ask for an updated policy would be superior.

[8] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth

[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01089.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01092.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01101.html

Replying specifically to the idea of an "Exempt" DanWalsh noted[12] that there were such policies (called "permissive domains") now available in Rawhide. He went on to restate the problem that "Teaching people to press a button to tell SELinux to disable protection [because of AVCs that don't really block anything will get them to disable it when a real attack comes along." Instead the SELinux developers are concentrating on eliminating many of the false AVCs and one of the recent changes towards this end is the addition of a new access permission "open". JamesMorris added[13] that he had written about this work, as implemented by EricParis, in his livejournal: "Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate "open" check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output."

[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01091.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01170.html

DanWalsh, in response to questions from ArthurPemberton,listed[14] the private information contained in an AVC denial as "Hostname, filename, potentially username, rpm information. What apps they are running."

[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01132.html

Dan was also concerned that any new upstream reporting only occurred when setroubleshoot had been unable to find a suggested fix in its database. He reported that many bugzilla entries filed against him appeared to indicate that users did not even attempt the actions indicated as potential fixes by setroubleshoot. ArjanvandeVen suggested[15] that setroubleshoot should just make those changes. DavidTimms wondered whether suggesting such "let this happen anyway" actions to users should be considered risky and not dissimilar to Ahmed's "Exempt" and "FixMe" buttons. He also listed several means by which he considered SELinux could be improved. DanWalsh replied[16] that many of these desired capabilities were already present in SELinux but appeared to ignore the behavioral similarities argued by David.

In response to further questions from ArthurPemberton it seemed[17] that the preferred mode for such a tool would be to suggest installation of any available updated policies either via PackageKit offering to install them or a "yum update".

[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01193.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01138.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01151.html

Process Wakeups and Energy Efficiency

UlrichDrepper posted[1] a systemtap script which revealed a list of applications which cause wakeups due to timeouts. He noted that "Programs should be woken based on events. They shouldn't poll data (which is what usually happens after a timeout)" and requested that package maintainers for the programs in the list try to help solve the issue. The Flash npviewer was clearly the worst offender. The creator of the PowerTOP program, ArjanvandeVen wondered[2] why this work could not have been done using PowerTOP.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00921.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00931.html

MatthewGarrett thought[3] that polling was inevitable for many applications but that the Glib timer function Template:G timeout add seconds[4], which allows a function to be called at repeated intervals until it is automatically destroyed, could be used to do this at low frequency. It turned out[5] that this was exactly the approach which ArjanvandeVen had taken. HaraldHoyer thought that this was non-ideal as it did not sync globally and while Matthew agreed that kernel support would be needed DavidWoodhouse speculated[6] that tackling the problem per-thread instead of per-event might be possible.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00938.html

[4] http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-timeoutadd-seconds

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00962.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00968.html

NilsPhilippsen added[7] that it should be possible to use IMAP IDLE to fix mail clients and servers that polled too frequently.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01032.html

RichardHughes quickly jumped[8] in to report a fix for his PackageKit problem but was less sanguine that GNOME Power Manager could be fixed quite so easily, although there was an expectation that Xorg would fix things by sending out a notification of changed DPMS state.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00948.html

DanielBerrange provided[9] some evidence that the apparent problem with libvirtd was actually due to DBus sending unrequested signals every six seconds. When DanWilliams took a look[10] at NetworkManager's contributions and explained some problems were due to the ipw2200 drivers waking up all WEXT listeners every four seconds and others were due to the presence of bogus rfkill switch events in HAL Daniel connected[11] the dots and said "Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux to be run every 6 seconds, which in turns causes any app connected to DBus system bus to be send a signal every 6 seconds and thus causes all the hits against libvirtd - and a fair number of other apps in that list too." DanWilliams responded that it was possible, but that it might be worth checking to see if D-Bus signal filtering was being done properly. The forthcoming 2.6.27 kernel was also said to contain the appropriate patches for rfkill which would help solve the problem.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00973.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00976.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00978.html

Problems with PulseAudio were guessed by LennartPoettering to be due to the aforementioned Flash player npviewer opening audio streams and never closing them which in turn caused PulseAudio to keep the device open. Again there was a promise of future improvement as Lennart mentioned that the version of PulseAudio in rawhide should not generate any wakeups when completely idle.

It would seem that Ulrich's initiative may yield some useful improvements.

Nodoka Notification Theme a Fedora 10 Feature

MartinSourada asked[1] for help determining whether his plan to provide a beautiful new notification theme for Fedora 10 counted as a "Feature" (see FWN#135 "New RPM Sparks Exploded Source Debate refs 10-20 for recent discussion of the Feature process.) The notification daemons are responsible for popping up small, dismissable windows informing the user that certain events have occurred[2][3].

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00842.html

[2] http://freedesktop.org/wiki/Specifications/systemtray-spec

[3] http://developer.gnome.org/doc/guides/platform-overview/platformoverview.html#notification-area

Martin stated that the public test release had been available for three months and no issues had been reported. He explained how to obtain the new theme from Koji and how to make it available to the system. After encouragement from RahulSundaram that such a visible change should be considered a feature Martin created a feature[4] page in the wiki. Further feedback from Rahul resulted[5] in the addition of screenshots and a Test Plan section.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00901.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00908.html

WillWoods wrote[6] a concise and informative overview of what was expected from Test Plans.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00912.html

Mono Beta

PaulJohnson announced[1] that a new beta of mono was about to hit the servers and would probably break a number of things. Also of note was the change of license to MIT for Mono-2.0.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01123.html

DavidNielsen was excited and wondered if this would be pushed into Fedora 8 and Fedora 9 once any obvious breakage had been fixed. BillNottingham did not think 2 that "breaking the entire ABI and licensing of mono in released distros is a *good* thing. Especially Fedora 8." David expressed the advantages of pushing out one big update with a completely revamped stack to which WillWoods replied[3] that it made more sense to wait for Fedora 10's release in three months' time. David returned[4] to the idea that "having the same Mono throughout our releases is easier to maintain [and] pushing newer versions of the stack will enable us to support applications more widely across the stack." He suggested shipping a Fedora 9 preview release and drew a parallel to the situation with KDE-4.1 and their QT libraries. KevinKoffler disputed[5] the parallel as "Qt-4.4 and KDE-4.1 aren't breaking binary compatibility[.]"

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01156.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01158.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01160.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01163.html

PaulJohnson explained[6] that until all the breakage had subsided only Rawhide would see the new beta "To me, rawhide is there for exactly this purpose - a testing ground to see how much is broken before pushing to stable." JeffSpaleta wondered 7 what the purpose of "updates-testing" was in that case.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01189.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01195.html

Policy On Non-Responsive Maintainers

The issue of non-responsive maintainers was aired[1] when PatriceDumas suggested a new policy designed to force maintainers to answer "easy fix" bugs or orphan packages. While Patrice worried that it might look rude he emphasized that the intent was to spread co-maintainership and obtain quicker bugfixes. While most contributors acknowledged the intent behind this they saw myriad problems.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/thread.html#00796

EricSandeen quickly raised[2] the problem of defining an "easy bug". AndrewBartlett thought[3] that this was potentially just "a stick to hit a stressed developer with - and surely developers under external stresses, who do not maintain Fedora packages as their day, job will be the ones most likely to have this stick waved at them. Their re-action may not be the one they or you want in the short and long term."

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00745.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00845.html

The issue of whether or not a fix had to, or could be, determined as correct was also seen[4] as a problem by BillNottingham and JesseKeating.

A very detailed and thoughtful response from MichaelSchwendt to MatejCepl outlined[5] the problem of increasing the volume of bureaucracy and email dealt with by maintainers. It's worth reading to understand the stresses mentioned by other posters including AdamJackson and NigelJones who described[6] typical volumes of email which they faced. Adam added that anyone was welcome to help him fix bugs. Michael suggested instead that there be "a policy for package maintainers to respond to specially marked tickets from fellow fedora contributors in a timely manner. And if that results in tickets which are still not answered, timeout periods can be applied and give contributors the opportunity to prepare a test update (and only a test update!)." JesseKeating liked[7] the idea and added that SIG meetings could help to triage bugs.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00894.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00937.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00856.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00939.html

HansdeGoede thought[8] that it would be better to address the problem of how to allow others to help make easy fixes. He argued that it ought to be possible to use ACLs to allow "easy fixes" to be committed by anyone with CVS extras permissions if a developer has allowed it. Patrice replied[9] that the cases which he was concerned about were not owned by maintainers who would allow such changes.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00757.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00764.html

Another voice against too much bureaucracy was that of RichardHughes who queried[10] "Surely the maintainer in question knows the package well enough to decide whether to merge patches? For instance, I might push a patch upstream and hold off applying it to fedora as it's trivial and will get updated at the next version bump of my package in a few weeks" to which KevinPage replied that there were examples where the timeframe was closer to numerous months. JeffSpaleta pushed[11] the idea of putting "packages under the purview of maintainer teams who are comfortable working with each other and care about the packages in question regardless of who the primary owner of a package is. SIGs are the obvious construct here[.]"

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01004.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01008.html

Refinement of the policy was carried out between RahulSundaram and ToshioKuratomi. Toshio wanted[12] to make it possible for a co-maintainer to be added in egregious cases to help ease the burden on the original maintainer.

[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00918.html

The emphasis on orphaning packages aggressively over a short time-period was questioned[13] by DanielBerrange. He suggested that adding co-maintainers would be a better strategy. RichardJones added[14] the disturbing spectre of "Wikipedia-style deletionism" occurring.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00946.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00982.html

Some balance was added by a post made[15] by KevinPage which conveyed the perspective of frustrated bugzilla posters who find their easy fixes ignored. Kevin explained his experience with trying to get his patches applied and wondered whether it was a consequence of the new emphasis on pushing bugfixes upstream. He finished with "One conclusion from this thread is that it's accepted that some maintainers don't follow bugzilla. Not condoned, but accepted as a reality. That's clearly incompatible with asking users to report their problems in bugzilla."

[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01005.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=40612"