Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
More and Wider Testing
In a thoughtful post Callum Lerwick suggested[1] that Fedora testing coverage could be improved in several inter-related areas. These included making Bugzilla easier to use; adding per-package rollbacks to enable reversion to known good states; blocking yum updates on specific reported bugs; providing a rescue image in /boot with the aforementioned functionality; and lastly, enabling simple installation of specific updates which might fix said reported bugs. Callum asked for respondents to eschew what he called the "Hard problem fallacy" which consisted of minor technical objections and asked them to provide answers modeled on the pattern of "You are an idiot and your ideas are stupid. We're not doing this."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01370.html
On the subject of rollbacks Jef Spaleta objected[2] that it was complicated by the triggered scripts in packages. Currently there are no tests for rollback and Jef wondered "...how do you set up a test which attempts to measure whether rollback across a trigger boundary put you back to where you were? How much of a different in state counts as 'break rollback' ?" He then added the problem of Obsoletes: "When an obsolete is introduced in an update... can we rollback and get what we had?" He finished off with the suggestion that Carrier Grade Linux might have some experience to offer as they had attempted rollbacks. Seth Vidal remembered[3] that "[...] the rollback functionality the CGL wanted was removed from rpm recently." Gilboa Davra asked[4] how it would be possible to pin-point what exactly had broken when there was a "150 package update push. Will you rollback all the updates? Only the updates that had _something_ to do with the breakage?" RalfCorsepius also nixed[5] the idea as "[...] package rollbacks will never work in general, because updates may contain non-reversable statefull operations (e.g. reformatting databases)."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01394.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01396.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01442.html
A comprehensive reply was made[6] by Gilboa Davra. In it he argued that automating bug reports lowered the signal-to-noise ratio considerable and objected to modification of yum to refuse updates until reported bugs are fixed: "Say-what?!? Are we building a second Vista here?" Although he liked the idea of a rescue image in /boot he cautioned that space considerations impinged upon the need to keep "[...] a different rescue image for each installed kernel unless you plan to keep the original kernel[.]" As regards selective updates he stated: "You can always enable updates-testing and selectively install what you need."
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409.html
A preliminary step was added[7] by Chris Lumens to those listed by Callum: "I'd like to add a step (0) before we make bugs easier to file and really crank up the number of reports we're getting: (0) More people FIXING the bug, not just reporting them. You can have a giant user base of people filing tons of bugs, and you can have a motivated and effective QA/Triaging team whittling them down to the really important and reproducable bugs. But without more people fixing them, the backlog is just going to continue to build."
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01421.html
When Peter Lemenkov wondered[8] why users were forced to register on Bugzilla Bill Nottingham underscored[9] the need for tools which do not swamp developers with large numbers of bugs. Alan Cox added[10] that the key was "[...] one clear and accurate bug report that happens to contain the right information and the user willing to help." Daniel P. Berrange further explained[11] that "[...] 90% [of bugs] are essentially useless when first reported. It requires several back/forth interactions between myself & the bug reporter to get enough information to diagnose & resolve the problem. If we create a system where we bombard maintainers with bugreports & no scope for user interaction they'll end up directly in /dev/null, and further discourage maintainers from addressing even bugs with enough info."
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01408.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01399.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01415.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01422.html
The Ubuntu tool apport was discussed[12] as a possible solution several times as was[13] the Debian tool reportbug.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01428.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01456.html
An emphasis was placed[14] on providing Bugzilla tools for developers and packagers by James Antill: "I won't mind getting 666 dups, or dealing with 10x as many bugs in general, as long as I have a decent local tool that can manage that number of bugs. Atm lots of TABs of open bugs, and giant folders of BZ email are the best tools I've seen."
[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01492.html
KarelZak jumped[15] straight to the original question and answered that testing participation was low "[...] because this work is not attractive. It's boring work without proper credit in open source community. It's very simple to found list of top-ten kernel developers, but who knows the most active bug reporters or QA around kernel? Nobody. People who are testing a software are real contributors. Our THANKS to them should be more visible!"
[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01696.html
Source File Audit Catches RPM Problems Early
Kevin Fenzi posted[1] the results from the latest run of his sources/patches URL checker script. There were 912 possible problems reported, which Kevin noted was "Up from 662 last run. This is a pretty sad increase."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01433.html
Happily many of the reported problems appeared[2] to be due to either temporary problems with GoogleCode and SourceForge project hosting or to some minor oddities in the script. Many of the other highlighted problems were confirmed as genuine and fixed by the package owners.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01450.html
Ian Weller contrasted[3] a successful run of spectool -g[4], which uses wget internally, with the failure of Kevin's script. Later Kevin also found[5] a similar result when examining another failure. He speculated "[...] it's working fine with a wget... perhaps they are blocking the agent that spectool -g uses? (which I am not sure what it reports)." Ville Skyttä offered[6] that "spectool -g uses plain wget, with configuration file /etc/fedora/wgetrc if it exists, otherwise usual system wget configs" and Thomas Moschny discovered[7] that "spectool uses -N, which seems to cause 404 errors with googlecode[.]" Jaroslav Reznik confirmed[8] this: "Same for me - it's not working for googlecode downloads. Wget with -N param sends HEAD instead GET - these two are same, but HEADs response are only headers - it's used for links validation etc... But looks is it misconfiguration on server side?" and thanked Kevin for the usefulness of his script which had caught a serious problem.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01434.html
[4] The spectool utility is part of rpmdevtools. It downloads and extracts sources and patches to build RPMs
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01451.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01454.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01459.html
Eric Sandeen asked[9] if it would be a good idea to extend rpmlint to perform these checks: "I'm most likely to fix this stuff if I'm in the middle of making some other change, and an automatic check while I'm working on a package that says `hey your source URL is no longer valid' would probably provoke me to fix it quickly. :)"
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01466.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01641.html
One Issue Tracker to Rule Them All
Arthur Pemberton examined[1] the challenge issued by Callum Lerwick to improve Bugzilla (see this same FWN#153 "More and Wider Testing".) He asked for a list features which distinguished Bugzilla from competitors.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01430.html
The ability of Bugzilla to deal with a massive number of "products, components, users, hits per second [with] clustering databases and similar magic" was advanced[2] by Matej Cepl as the most compelling reason. Nicholas Mailhot added[3] "feature completeness, familiar UI, integrating with upstream issue trackers (which are often bugzilla too)" and Emmanuel Seyman suggested[4]: "And as an encore : it has to contain 109900+ bugs of existing data so that we don't lose any history."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01470.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01477.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01483.html
A certain amount of impatience with the general idea was expressed[5] by Matej Cepl when he agreed with Andrew Cagney that one essential feature would be a "push upstream" button: "AMEN!!! And I think we should concentrate on this rather than doing stupid bugzilla rewrites. Sorry, for being harsh, but it is so IMNSHO." Emmanuel Seyman warned[6] that it would be necessary to map users, bugs and components across any separate upstream/downstream instances of bugzilla. He later expanded[7] upon this: "Bugzilla has gained the abilty to customize statuses and resolutions, making it even harder to push bugs from one bugzilla to another with prompting for user interaction." LaunchPad[8] was discussed[9] as possibly providing this feature. Casey Dahlin noted[10] that cross-site integration was still not implemented "[...] because there should never ever ever be two independent sets of launchpad data ever, according to their philosophy [.]"
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01611.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01615.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01622.html
[8] Canonical's collaborative hosting service https://launchpad.net/
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01616.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01539.html
Till Maas suggested[11] several interesting improvements including "[...] the possibility of having several people beeing responsible for a Component, which is currently only partly possible. There is the initial CC list, but when a bug is reassigned to a different component, the members of the initial CC list of the old component are not removed from the list." Other desiderata included storing the NEVR of a package in a dedicated field and support for the same bug across several different releases.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01612.html
The issue of how bugs can actually be fixed cropped up again in the discussion. Brennan Ashton suggested[12] that triaging bugs was an area in need of volunteers and provided a link[13] to the BugZappers wiki page.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01704.html
[13] https://fedoraproject.org/wiki/BugZappers
RFC: Fix Summary Text for Lots of Packages
Richard Hughes wished[1] that the Packaging Guidelines on summaries and descriptions would be followed a little more closely as "[q]uite a lot of packages have summary text that is overly verbose, and this makes the GUI and output from pkcon look rubbish."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01484.html
Josh Boyer warned[2] against making reviewers' jobs harder by codifying too much in the package guidelines and suggested: "Just file bugs for packages you think are overly verbose. Offer alternate summaries in the bug, and a URL to your email for rationale." Bill Nottingham was[3] dubious that "[...] this scales across 5000 packages. So it would be good to have at least *something* in the guidelines." When Richard compromised on a "soft guideline such as: Summary should aim to be less than 8 words" David Woodhouse gently poked[4] fun at this summary as being too wordy.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01487.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01489.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01493.html
Toshio Kuratomi expressed[5] disapproval of soft guidelines due to their potential for sparking many individual disagreements instead of one single point of contention being handled by the Packaging Committee. Richard seemed happy enough with Toshio's suggestion[6] that the packaging guidelines contain a "best practice" description with examples.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01495.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01499.html
When Bill Nottingham raised[7] the possibility of "summary collisions" Jef Spaleta threw out[8] an analogy based on searching for medicine in a grocery store in a foreign country. This was intended to stimulate clarification of the function of summaries. Toshio Kuratomi loved[9] it and suggested that summaries were like the "[...] little advertising gimicks seen on and alongside the other things on the bottle. Things like: "New!", "Larger size", [Picture of grapes and smiling child], etc. They're differentiators that "help" you choose one product over another." He provided some concrete examples which seemed to prove his case.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01520.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01536.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01569.html
Michal Hlavinka worried[10] that yum search <keyword> would be disrupted but Michael Schwendt re-assured[11] him that "'yum search' also searches the package %description. And the description is the place where to be much more verbose than in the summary. The %summary is not made for searching, but for enabling the installer and packaging tools to to display a brief and concise package description or a list thereof. That means, put a few relevant keywords in the summary (newspaper headline-style at most), but avoid long/complete sentences as often as possible. That also makes it easier to fit into one line."
[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01500.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01510.html
Later Richard asked[12] for opinions on a sample email which he intended to send out to some maintainers to alert them to their long package summaries.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01640.html
Andrea Musuruane, as an RPM Fusion packager, felt[13] that packagers' time would be wasted in following the proposal and that a "Summary is something that the packager should choose on his own. It must be less than 80 characters and _maybe_ it should not contain the package name. Everything else is just marketing. If someone thinks that adding the fact that the application is based on Gnome, it is fine for me. If someone else thinks that mentioning that other application uses DBUS it is fine for me too." Richard clarified[14]: "I'm _not_ saying "change your summary or we'll drop your package" I'm asking them to come into line with 90% of the other packages in the distro. I'm even offering to do the cvs commit myself, if they give me the new summary line."
[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01654.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01656.html
The issue of these changes being made solely to accommodate PackageKit was addressed[15] by James Antill: "The fact that a single tool decided that summaries should be used instead of names, and so summaries should be roughly the same size of names shouldn't make Fedora packages break their summaries for other tools ... all IMO." When Emmanuel Seyman asked[16] exactly how GUI packaging tools made the summary more prominent than the package name Richard Hughes responded[17] that it was actually one, but one that was exposed in many places. Emmanuel's response was blunt: "FWIW, I don't appreciate our maintainers being lied to. The vast majority of them work hard to make their packages and I believe that a minimum of respect should be shown [...] it is a case of changing one application versus changing 500." Ville Skyttä took[18] an overview which left the current user-interface of gnome-PackageKit aside and concentrated on whether there was agreement that rpmlint should be taught to check that the package name should not be repeated in the summary.
[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01683.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01672.html
[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01713.html
[18] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01673.html
Further criticism was made[19] by Christopher Wickert of sorting packages by description instead of name in PackageKit and Tom Lane raised[20] the problem of sub-packages needing to reference the name of their parent package. At this stage it seemed that some consensus had been reached on the idea that summaries which repeated the program name were frowned upon and that "verb phrases" should be also be deprecated as suggested[21] by Ignacio Vazquez-Abrams.
[19] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01721.html
[20] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01733.html
[21] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01532.html
A brief dispute between Andreas Musuruane and Michael Schwendt yielded a closing statement which seemed[22] to make the case of those that favor the changes in a strong manner. Michael accepted that: "[i]t isn't trivial to come up with good one-line summaries that do more than repeating the program name. It's nothing packagers like to spend time on. Reducing a packager's freedom even further won't be a good thing [...] I think with some people one could argue endlessly about pkg summaries. And during pkg reviews that's wasted time. Still, with very old repositories it has been noticed [and agreed on, mostly] that some types of summaries simply look poor in Anaconda and package management tools. That was the rationale for some of the recommendations." RichardHughes noted[23] that over the last forty-eight hours many maintainers had changed their package summaries as requested.
[22] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01753.html
[23] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01764.html
Smock: Simpler Smock for Chain Building
A couple of announcements were made by Richard Jones. The first was of a new version of OCaml. The second was[1] of a wrapper script that "[...] runs on top of mock, allowing you to chain-build a series of RPMs from a single command." An example which would "[...] arrange the SRPMs into the correct order according to their BuildRequires, then build each in the four separate mock environments Fedora {9,10} {i386,x86_64}" was provided:
smock.pl --arch=i386 --arch=x86_64 \ --distro=fedora-9 --distro=fedora-10 \ *.src.rpm
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01229.html
Till Maas suggested[2] that local file access URIs[3], such as file:///, could be used to avoid the need for a webserver and Paul Howarth confirmed[4] that he had been using mock "[...] like this for *years* with loopback-mounted ISO images for a low-cost source for the base repo. It definitely works."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01232.html
[3] See RFC1738 section 3.10 http://tools.ietf.org/html/rfc1738
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01264.html
Seth Vidal asked[5] why the wrapper approach had been taken instead of integrating the functionality into mock and Richard agreed[6] that this should happen. An initial problem with build requires of the form "%{name}-devel" failing was quickly fixed[7].
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01238.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01239.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01354.html