Fedora Weekly News #153 Developments
== 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 Mock 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
